sbergman at redhat.com
Tue Apr 22 04:11:01 PDT 2014
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.
> (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] 
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".
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
> 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.
More information about the LibreOffice