Log4cxx
  1. Log4cxx
  2. LOGCXX-193

Please rename or remove new local variable "buf" in Logger.h macros

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.10.0
    • Fix Version/s: 0.10.0
    • Component/s: Appender
    • Labels:
      None
    • Environment:
      All environments.

      Description

      The new logging macros have a dangerous new feature, ie the local variable buf

      #define LOG4CXX_LOG(logger, level, message) { \
      if (logger->isEnabledFor(level)) {\
      ::log4cxx::helpers::MessageBuffer buf; \ <--------------- ****** broke my build!!!
      logger->forcedLog(level, buf.str(buf << message), LOG4CXX_LOCATION); } }

      I upgraded from 0.97 HEAD to 0.10.0 HEAD and my build broke, since my source code also uses many local variables called "buf" which get logged.

      Please consider either eliminating the named local variable altogether, or giving it an implementation-level name, eg _buf_.

      Many thanks!

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Closed Closed
        5d 3h 49m 1 Curt Arnold 01/Oct/07 23:56
        Curt Arnold made changes -
        Field Original Value New Value
        Status Open [ 1 ] Closed [ 6 ]
        Fix Version/s 0.10.0 [ 10782 ]
        Resolution Fixed [ 1 ]
        Hide
        Allan Erskine added a comment -

        my message parameter was actually a variable called buf, so the macro was expanding as:

        ... buf.str(buf << buf) ...

        ie trying to stream itself!

        Thanks for the speedy response!

        Show
        Allan Erskine added a comment - my message parameter was actually a variable called buf, so the macro was expanding as: ... buf.str(buf << buf) ... ie trying to stream itself! Thanks for the speedy response!
        Hide
        Curt Arnold added a comment -

        I could see it resulting in a warning that it was shadowing an existing variable, but it shouldn't be a error unless you had promoted warnings to errors. But avoiding the warning is still a desirable thing.

        The change was actually to restore a "feature" that had been present in 0.9.7, the ability to use insertion operators in the message parameter of the macro. The 0.9.7 macro had a local variable in the same location, but was named "oss" not "buf" which could result in the same problem but is less likely to do so.

        I did a quick Google search and found that the Ghostscript C coding guide suggested a single trailing underscore for variables in macro expansions.

        Changed the name to "oss_" in rev 579809. I do think there is a way to get the desired behavior (see recent post on log4cxx-dev) without introducing a local variable name. Hopefully, you don't have any variables named "oss_".

        Thanks for the feedback.

        Show
        Curt Arnold added a comment - I could see it resulting in a warning that it was shadowing an existing variable, but it shouldn't be a error unless you had promoted warnings to errors. But avoiding the warning is still a desirable thing. The change was actually to restore a "feature" that had been present in 0.9.7, the ability to use insertion operators in the message parameter of the macro. The 0.9.7 macro had a local variable in the same location, but was named "oss" not "buf" which could result in the same problem but is less likely to do so. I did a quick Google search and found that the Ghostscript C coding guide suggested a single trailing underscore for variables in macro expansions. Changed the name to "oss_" in rev 579809. I do think there is a way to get the desired behavior (see recent post on log4cxx-dev) without introducing a local variable name. Hopefully, you don't have any variables named "oss_". Thanks for the feedback.
        Allan Erskine created issue -

          People

          • Assignee:
            Curt Arnold
            Reporter:
            Allan Erskine
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development