Closed gojimmypi closed 9 months ago
Any reason to not just use
WOLFSSL_IGNORE_FILE_WARN
in your user_settings.h? That option covers several other places too.
Yes: my final solution was to exclude the misc.c
in the build and not trigger the warning at all. The issue is that when I first saw the "MISC_WARNING" it was not very intuitive. This PR prints the intended message as desired. If there's going to be a warning, it should print the proper text.
I did the change for the MISC_WARNING string. I don't know why I did it that way, but it should probably go back to just being a string on the #warning directive. I suppose we could switch to using _Pragma, but that's going to be the first one. I don't care about duplicating the string there, it isn't compiled code.
I suppose we could switch to using _Pragma, but that's going to be the first one.
I'm ok to go back to the simpler code & duplicate the compile-time text warning. There's otherwise no compelling reason to introduce new things. Just let me know which you prefer.
I've reverted the defined MISC_WARNING
macro string to the simpler, duplicated text.
As noted in https://github.com/wolfSSL/wolfssh/issues/633, when building with the Espressif ESP-IDF, and the
misc.c
is not excluded in theCMakeLists.txt
, I see this message:In particular, note the
MISC_WARNING
was previously defined as a descriptive string, but that string is not displayed at compile time.This PR adds some macro logic to detect if
_Pragma
is supported, and if so the contents ofMISC_WARNING
is string-ified and displayed as appropriate.Although this might have been simplified by simply using the same string in multiple places, there may be value in having the single definition of
MISC_WARNING
available elsewhere as needed.Using this change, the warning is manifested like this in my environment: