On 04/20/2014 11:03 AM, julien2412 wrote:
I gave a try to cpplint
(http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py) with
some changes so it scan subdirectories.
Except pure formatting warnings, it reports things like this:
1) ./drawinglayer/source/primitive2d/polygonprimitive2d.cxx:274: Consider
using rand_r(...) instead of rand(...) for improved thread safety.
[runtime/threadsafe_fn]
(other functions quoted in the py script:
asctime_r, ctime_r, getgrgid_r, getgrnam_r, getlogin_r, getpwnam_r,
getpwuid_r, gmtime_r, localtime_r, strtok_r, ttyname_r)
If this use of rand() is really about the function from stdlib.h (and
not some other function that happens to have the same name; didn't
check), one problem with the advice is that rand_r is Posix (and
deprecated, at that) but not ISO C.
2) ./fpicker/source/win32/filepicker/comptr.hxx:100: Unary operator& is
dangerous. Do not use it. [runtime/operator] [4]
Yeah, that one looks scary indeed.
3) ./crashrep/source/unx/main.cxx:64: For a static/global string constant,
use a C style string instead: "static char g_strProductKey[]".
[runtime/string]
Looks like a false positive, as
static string g_strProductKey;
is not used to hold a statically known string constant.
4) ./sd/source/ui/remotecontrol/Transmitter.cxx:10: Streams are highly
discouraged. [readability/streams]
Beats me what's wrong with
#include <iostream>
in general.
5) ./sd/source/ui/remotecontrol/mDNSResponder/CommonServices.h:488: Are you
taking an address of a cast? This is dangerous: could be a temp var. Take
the address before doing the cast, rather than after [runtime/casting]
Looks like cpplint is confused here, as
&( (const struct sockaddr_in *)( SA ) )->sin_addr
clearly needs to cast before taking the adr of pointed-to member.
6) ./include/comphelper/sequenceashashmap.hxx:81: Single-argument
constructors should be marked explicit. [runtime/explicit]
There can be no hard-and-fast rule for that. While some ctors probably
miss an "explicit," others deliberately are not explicit.
7) ./oox/source/helper/binaryoutputstream.cxx:122: Do not use
variable-length arrays. Use an appropriately named ('k' followed by
CamelCase) compile-time constant for the size. [runtime/arrays]
While the advice to not use variable-length arrays is generally sound,
the suggestion is of course nonsense here (though using OUStringBuffer
or std::vector<sal_Unicode> could arguably be an improvement).
There are other different types of warnings about headers/include guards but
would you have some opinion about these first?
Looks like a rather poor signal/noise ratio to me.
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
