Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LOG COLOR STILL ERROR ON BUILD by wront type INT vs UINT32_T (IDFGH-12189) #13244

Closed
3 tasks done
filzek opened this issue Feb 23, 2024 · 4 comments
Closed
3 tasks done
Labels
Resolution: Won't Do This will not be worked on Status: Done Issue is done internally Type: Bug bugs in IDF

Comments

@filzek
Copy link

filzek commented Feb 23, 2024

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

5.2

Espressif SoC revision.

esp32

Operating System used.

Windows

How did you build your project?

Command line with Make

If you are using Windows, please specify command line type.

None

Development Kit.

esp32

Power Supply used.

USB

What is the expected behavior?

C:/Espressif/frameworks/esp-idf-v5.2/components/log/include/esp_log.h:291:27: error: format '%d' expects argument of type 'int', but argument 6 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
291 | #define LOG_COLOR(COLOR) "\033[0;" COLOR "m"

why espressif doenst fix this right away, everyone complain about it but no one takes action to a simple question???

What is the actual behavior?

work as intent, if the compiler has PROBLEM fix the code to work as the compiler wants it to do, its impossible in 2024 that a simple question couldnt be addressed right away.

Steps to reproduce.

try to build any log color app will bring error.

C:/Espressif/frameworks/esp-idf-v5.2/components/log/include/esp_log.h:291:27: error: format '%d' expects argument of type 'int', but argument 6 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
291 | #define LOG_COLOR(COLOR) "\033[0;" COLOR "m"

Debug Logs.

C:/Espressif/frameworks/esp-idf-v5.2/components/log/include/esp_log.h:291:27: error: format '%d' expects argument of type 'int', but argument 6 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
  291 | #define LOG_COLOR(COLOR)  "\033[0;" COLOR "m"

More Information.

C:/Espressif/frameworks/esp-idf-v5.2/components/log/include/esp_log.h:291:27: error: format '%d' expects argument of type 'int', but argument 6 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
291 | #define LOG_COLOR(COLOR) "\033[0;" COLOR "m"

@filzek filzek added the Type: Bug bugs in IDF label Feb 23, 2024
@espressif-bot espressif-bot added the Status: Opened Issue is new label Feb 23, 2024
@github-actions github-actions bot changed the title LOG COLOR STILL ERROR ON BUILD by wront type INT vs UINT32_T LOG COLOR STILL ERROR ON BUILD by wront type INT vs UINT32_T (IDFGH-12189) Feb 23, 2024
@igrr
Copy link
Member

igrr commented Feb 23, 2024

Hi @filzek, please check this section of the migration guide: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides/release-5.x/5.0/gcc.html#int32-t-and-uint32-t-for-xtensa-compiler.

If you can't change the application code to use the inttypes.h format specifiers (PRId32 and so on) then you can disable format string warnings in your component CMakeLists.txt file, like this.

(I have explained the reason for this change in replies over at #9511, if you need more details.)

@filzek
Copy link
Author

filzek commented Feb 24, 2024

Understood, but somehow if was is to add from the SDK a compiler flag to do not bring this warn/error for it, like to auto add the lib flag in the compiler, and in the menuconfig bring the option to disable it, so could be much more user understandable.

@igrr
Copy link
Member

igrr commented Feb 26, 2024

Well, adding -Wno-format flag to the compilation flags of the component is just one line in CMake, and we didn't want to set the precedent of adding a Kconfig option for every compiler warning flag — as that would be an endless number of things to maintain and test. Besides, we support both GCC and Clang toolchains now, and they don't share exactly the same compiler flags in all cases. So adding this Kconfig options is probably something we won't do, sorry.

@filzek
Copy link
Author

filzek commented Feb 27, 2024

Well, adding -Wno-format flag to the compilation flags of the component is just one line in CMake, and we didn't want to set the precedent of adding a Kconfig option for every compiler warning flag — as that would be an endless number of things to maintain and test. Besides, we support both GCC and Clang toolchains now, and they don't share exactly the same compiler flags in all cases. So adding this Kconfig options is probably something we won't do, sorry.

Sure, I understand. Closing it!

@filzek filzek closed this as completed Feb 27, 2024
@espressif-bot espressif-bot added Status: Done Issue is done internally Resolution: Won't Do This will not be worked on and removed Status: Opened Issue is new labels Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Won't Do This will not be worked on Status: Done Issue is done internally Type: Bug bugs in IDF
Projects
None yet
Development

No branches or pull requests

3 participants