The name was misleading as it was actually a `long long` and also if we
ever move to an (optional) 128-bit value it wouldn't even less fitting.
We should name it to match our alias type.
It was also used inconsistently and seemed to imply there is some
special handling which wasn't the case. It was just an alias for
`std::to_string()` for non-`double` types. So there was no need for it.
---------
Co-authored-by: Robert Reif <reif@earthlink.net>
* fixed#11428 - improved handling of suffices in `MathLib::to{Double|ULong|Long}Number()`
* testmathlib.cpp: adjustments for `libc++`
* mathlib.cpp: added TODO
* Refactor isNullOperand out of FwdAnalysis
* Improve isNullOperand
* Fix redundantAssignment FP with unsigned zero
* isNullValue check number
* Enhance isNullOperand to handle c++ casts
Also handle cast of NULL.
* cppcheck.cpp: Check for JSON error when parsing addon .json files
This fixes that errors in JSON files given via `--addon=*.json` are
silently ignored and maybe only a part of the JSON file is used.
Now the error message which picojson can return is checked and a
corresponding error message is returned again by getAddonInfo().
* naming.json: Fix missing comma
* CLI: Fix naming violations detected by addon naming.py via naming.json
* Addon naming: Add argument for validating names of constants
* LIB: Rename functions/variables so they are valid, loosen naming rules
* GUI: Fix naming violations
Keeping the prefix in the token allows cppcheck to print the correct
string and char literals in debug and error messages.
To achieve this, move some of the helper functions from token.cpp to
utils.h so that checks that look at string and char literals can reuse
them. This is a large part of this commit.
Note that the only user visible change is that when string and char
literals are printed in error messages, the prefix is now included.
For example:
int f() {
return test.substr( 0 , 4 ) == U"Hello" ? 0 : 1 ;
};
now prints U"Hello" instead of "Hello" in the error message.
Building with enhanced clang warnings indicated a large number of
instances with the warning:
`warning: zero as null pointer constant`
Recommended practice in C++11 is to use `nullptr` as value for
a NULL or empty pointer value. All instances where this warning
was encountered were corrected in this commit.
Where warning was encountered in dependency code (i.e. external library)
no chnages were made. Patching will be offered upstream.
George Sokianos
Oliver Stöneberg
chrchr-github
Carl Morgan
Daniel Marjamäki
PKEuS
orbitcowboy
Paul Fultz II
Yichen
IOBYTE
Rikard Falkeborn
Sebastian
Scott Furry