From PVS Studio:
V808
'noproxy' object of 'basic_string' type was created but was not utilized.
https://www.viva64.com/en/w/V808/print
Signed-off-by: Vitalii Koshura <lestat.de.lionkur@gmail.com>
From PVS Studio:
V730
Not all members of a class are initialized inside the constructor.
Consider inspecting: present.
Consider inspecting: handle.
https://www.viva64.com/en/w/V730/print/
Signed-off-by: Vitalii Koshura <lestat.de.lionkur@gmail.com>
From PVS Studio:
V667:
The 'throw' operator does not possess any arguments and is not situated within the 'catch' block.
https://www.viva64.com/en/w/V667/print/
Signed-off-by: Vitalii Koshura <lestat.de.lionkur@gmail.com>
This was not working because the manager was not detecting its own executable name and path so it couldn't start a new instance of itself. Windows and Mac use different codepaths so it worked there.
The new library function can be extended for Windows and Mac to avoid code duplication.
Remove "-L$(libdir) -rapth $(libdr)" from LDFLAGS of boinc libraries in
Makefile.am of api, lib, sched and zlib directories to be able to
cross-compile boinc.
Indeed, libdir is not equal to the path where BOINC will be installed
but to exec_prefix/lib. The full installation path is
$(DESTDIR)/$(libdir).
To cross-compile boinc, exec_prefix will be set to the target path (for
example: /usr) and DESTDIR will be set (during make install) to the
staging or target directory on the host (for example /home/xxx/target).
The issue of adding -L$(libdir) is that it is not allowed by the
compiler, the error "unsafe header/library path used in
cross-compilation: '-L/usr/lib'" will be raised.
As a result, remove "-L$(libdir) -rapth $(libdr)" from LDFLAGS, the
default library search paths are sufficient for "standard" compilation
or can be updated manually by passing the additional search path to
LDFLAGS during the configure call for cross-compilation.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Note also that Apple has deprecated the UNIX standard call system(const char *) as ofd OS 10.10 and says to use posix_spawn() calls instead. I have added a macro to the precompiled header MacGUI.pch for the Manager builds that converts the calls automatically, but have not been able to do so for the other BOINC modules. If future code in the client, libraries, etc. calls system(), this will have to be handled on a case by case basis, as I have done in boinc_rename_aux() in lib/filesys.cpp and CLIENT_STATE::write_state_file() in client/cs_statefile.cpp.
Currently, execinfo.h is included in lib/diagnostics.cpp if __GLIBC__ is
defined. However, this does not work when cross-compiling boinc with
uclibc-ng. So, instead, check the presence of execinfo.h in configure.ac
and update lib/diagnostics.cpp accordingly.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
This define was introduced to winternl.h on 2012-07-12 but I couldn't find out which version that corresponds to. At least version 2.0.1-1 of mingw-w64-dev in Ubuntu 12.04 LTS does not define it.
VS lets you choose the compiler warning level, 0 to 4.
Higher is good because compiler warnings often indicate bugs.
However, some warnings are noise, and having a lot of them is bad
because they conceal the important ones.
As an example, a recent update to VS2010 causes it to spew warnings of the form
"function _strdup() is deprecated; use _strdup() instead.
So the new policy is:
- everything compiles with warning level 4
- in boinc_win.h we use #pragmas to suppress 3 specific warnings
that occur a lot in our code, and are not bugs:
- the _function names as described above
- constant conditional expression (like while(1))
- conversion from int to char
And the goal is to build everything with zero warnings
except from outside code like zip.
We're pretty close to that.
The project files for other VS versions should be modified
to also use level 4 everywhere.
- The RPC handler was expecting the "BOINC names" to be the file MD5.
This is no longer true; the BOINC name can be anything as long as it's unique.
- To reflect this, use <phys_name> instead of <md5> in request messages.
This means that you'll need to update both RPC client and server software.
- BoincJobFile::insert() needed to return the insert ID
This supports the TACC use case,
in the jobs in a batch can use different Docker images
and different input and output file signatures,
none of which are known in advance.
Python API binding:
- A JOB_DESC object can optionally contain wu_template and result_template
elements, which are the templates (the actual XML) to use for that job.
Add these to the XML request message if present.
- Added the same capability to the PHP binding, but not C++.
- Added and debugged test cases for both languages.
Also, submit_batch() can take either a batch name (in which case
the batch is created) or a batch ID
(in which the batch was created prior to remotely staging files).
RPC handler:
- in submit_batch(), check for jobs with templates specified
and store them in files.
For input templates (which are deleted after creating jobs)
we put them in /tmp,
and use a map so that if two templates are the same we use 1 file.
For output templates (which have to last until all jobs are done)
we put them in templates/tmp, with content-based filenames
to economize.
- When creating jobs, or generating SQL strings for multiple jobs,
use these names as --wu_template_filename
and --result_template_filename args to create_work
(either cmdline args or stdin args)
- Delete WU templates when done
create_work.cpp:
handle per-job --wu_template and --result_template args in stdin job lines
(the names of per-job WU and result templates).
Maintain a map mapping WU template name to contents,
to avoid repeatedly reading them.
For jobs that don't specify templates, use the ones specified
at the batch level, or the defaults.
David Anderson