ASF subversion and git services commented on GEODE-6007:

Commit 104bda4c872b0eda73bc70b70a51abd7e4a11381 in geode-native's branch 
refs/heads/develop from Blake Bender
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=104bda4 ]

GEODE-6007: Fix LGTM issues (#517)

* Fix most of the LGTM issues.  There are a few stragglers, but it's difficult 
to find them in the LGTM web UI among the 80+ others, so we'll fix these and 

> Fix LGTM complaints in NC code base
> -----------------------------------
>                 Key: GEODE-6007
>                 URL: https://issues.apache.org/jira/browse/GEODE-6007
>             Project: Geode
>          Issue Type: Improvement
>          Components: native client
>            Reporter: Blake Bender
>            Priority: Major
>          Time Spent: 1h 10m
>  Remaining Estimate: 0h
> This is showing stuff that is bad practice in general, and may open us up to 
> maliciousness.  There are two main situations in which we find lots of usage 
> of snprintf with raw char buffers, which are:
>  * formatting messages for exceptions
>  * formatting messages for logging
> For the exception messages, we should switch to something known to be safe - 
> a vsxprintf implementation, boost::format, std::stringstream, whatever.  As 
> long as we stop declaring raw char buffers on the stack, it's all good
> For logging, the situation is even dumber.  The various LOG* macros in the 
> code _already_ take a format string and varargs, so as far as I know we 
> essentially need to move the printf-style arguments into the logging macro 
> and get rid of the other nonsense.  We may even buy a tiny performance 
> improvement due to the fact that that logging macros can be compiled out of 
> the code.
> UPDATE:  Report from running LGTM on our code may be found at 
> [https://lgtm.com/projects/g/apache/geode-native/alerts/?mode=list.]  This 
> report has issues with tons of printf-style format specifiers, so it catches 
> most of the snprintf stuff pointed out above.  MANY OF THESE ARE BUFFER 
> OVERFLOW ISSUES, and must be addressed in the name of security.

This message was sent by Atlassian Jira

Reply via email to