Conflicting definitions of LOG_ERR in logging/log.h and posix/syslog.h

[besmarsh]

Describe the bug

LOG_ERR is a constant defined by POSIX and defined in include/zephyr/posix/syslog.h. Zephyr's logging subsystem also defines LOG_ERR as a macro to write an error level message to the log.

These definitions are conflicting. This causes a compile-time warning. This also causes a compile-time error if the version of LOG_ERR that is included first is used by an application. The order of includes ends up determining whether an application using LOG_ERR and including both logging/log.h and syslog.h (directly or indirectly) will compile.

Applications using the POSIX API that would otherwise be compatible with Zephyr can fail to compile due to this issue.

I noticed in the XSI system logging test this issue being worked around by undefining LOG_ERR and manually defining _LOG_ERR. This isn't really a generally acceptable solution when compiling POSIX-based code for Zephyr.

Since LOG_ERR is specified by POSIX, the Zephyr logging macro would probably need to be renamed to fix this issue.

Regression

• This is a regression.

Steps to reproduce

1. Add the following to samples/hello_world/prj.conf:

CONFIG_POSIX_API=y
CONFIG_LOG=y
CONFIG_XSI_SYSTEM_LOGGING=y

2. Add the following to the includes section of samples/hello_world/src/main.c:

#include <syslog.h>
#include <zephyr/logging/log.h>

3. Add the following to samples/hello_world/src/main.c:main():

syslog(LOG_ERR, "Error");

4. west build -b <board> samples/hello_world

Relevant log output

In file included from <...>/zephyrproject/zephyr/samples/hello_world/src/main.c:10:
<...>/zephyrproject/zephyr/include/zephyr/logging/log.h:48: warning: "LOG_ERR" redefined
   48 | #define LOG_ERR(...)    Z_LOG(LOG_LEVEL_ERR, __VA_ARGS__)
      |
In file included from <...>/zephyrproject/zephyr/samples/hello_world/src/main.c:9:
<...>/zephyrproject/zephyr/include/zephyr/posix/syslog.h:42: note: this is the location of the previous definition
   42 | #define LOG_ERR     3
      |
<...>/zephyrproject/zephyr/samples/hello_world/src/main.c: In function 'main':
<...>/zephyrproject/zephyr/samples/hello_world/src/main.c:15:16: error: 'LOG_ERR' undeclared (first use in this function)
   15 |         syslog(LOG_ERR, "Error");
      |                ^~~~~~~

Impact

Functional Limitation – Some features not working as expected, but system usable.

Environment

• OS: Windows
• Toolchain: Zephyr SDK (arm-zephyr-eabi)
• Commit SHA: 31ef45e

Additional Context

No response

[ljd42]

Thanks @besmarsh for your report. Was this report AI generated?

IMHO, it's not a bug as using both Zephyr logging and syslog at the same time is somewhat antinomic. If we use the POSIX abstraction, we want to hide the Zephyr (logging) interface behind it! It's like using an European plug adapter for UK socket, and then complaining we can't plug UK plug anymore with that adapter...

Having both syslog and Zephyr's native logging is possible, but we need to deal with the LOG_ERR collision, as you mentioned. The solution exposed in tests/posix/xsi_system_logging/src/main.c is probably one of the easiest way to do this.

[besmarsh]

Thanks @besmarsh for your report. Was this report AI generated?

IMHO, it's not a bug as using both Zephyr logging and syslog at the same time is somewhat antinomic. If we use the POSIX abstraction, we want to hide the Zephyr (logging) interface behind it! It's like using an European plug adapter for UK socket, and then complaining we can't plug UK plug anymore with that adapter...

Having both syslog and Zephyr's native logging is possible, but we need to deal with the LOG_ERR collision, as you mentioned. The solution exposed in tests/posix/xsi_system_logging/src/main.c is probably one of the easiest way to do this.

Not AI generated. I'll take that as a compliment that my report is well-written and clear.

I kind of agree that using both Zephyr logging and syslog would be a bit odd, if you were explicitly using both together.

However the issue as I see it is using code (potentially a third-party library that you don't want to hack) that uses POSIX syslog where Zephyr logging ends up being indirectly included. For example, using a library that uses POSIX syslog and BSD sockets - Zephyr's networking subsystem will be indirectly included and use Zephyr logging. If syslog gets included second, then you can get away with build warnings (still not ideal), but if Zephyr's logging gets included second then syslog can't be properly used.

To try to adapt your analogy, that would be something like wanting European sockets and depending on which electrician installs the sockets, ending up with either European or UK sockets. Having to workaround the issue in a library would then be like hacking the off-the-shelf power supply used for your device to change the plug on it to match the incorrect socket.

[cfriedt]

@besmarsh - this is actually not a bug in POSIX.

It's a bug in Zephyr's log subsystem, since that used symbols that conflict with a widely published and well established (for 20 years?) standard.

There is no way to "fix" this, as it is part of the POSIX standard. We do have a workaround, as mentioned.

It's been brought up already, but I will reassign.

[ljd42]

Not AI generated. I'll take that as a compliment that my report is well-written and clear.

I pondered a while if I should ask the question. I thought myself, this will be awkward if it's not AI, and here I am now 🙈 🤣

I was somewhat intrigued by this report: clear-and-easy to follow style with a sound technical reasoning. AI can imitate the style but the technical reasoning is mostly nonsensical ( good examples are discussed by the curl maintainers ). I was curious if you got helped by AI along the way to formulate the report.

However the issue as I see it is using code (potentially a third-party library that you don't want to hack) that uses POSIX syslog where Zephyr logging ends up being indirectly included.
[...]
to try to adapt your analogy, that would be something like wanting European sockets and depending on which electrician installs the sockets, ending up with either European or UK sockets.

The use cases I thought of were too narrow! I perfectly see your point, thanks.

@cfriedt has already confirmed the bug.

P.S: I had this a similar kind of electrician at my home!