[
https://issues.apache.org/jira/browse/GEODE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender updated GEODE-6007:
--------------------------------
Description:
This 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.
was:
This 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.
> Remove use of snprintf 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
>
> This 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
(v7.6.3#76005)
