Re: Äbout cpplint

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