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

Formatting of null-pointers (char*)? #1009

Closed
tomscii opened this issue Feb 27, 2019 · 8 comments
Closed

Formatting of null-pointers (char*)? #1009

tomscii opened this issue Feb 27, 2019 · 8 comments

Comments

@tomscii
Copy link

tomscii commented Feb 27, 2019

Hi,

I am using spdlog 1.3.1 with bundled fmt on MacOS X.

Not sure if this is a bug or a feature. If I have a char* (C-string) that is sometimes a nullptr, and in that case I get this when attempting to log it (nothing fancy, just spdlog::debug("ptr={}\n", ptr);):

[*** LOG ERROR ***] [2019-02-27 12:43:18] [] string pointer is null

Naturally, I get the correct log output when ptr is non-null and points to a valid C-string.

What I would prefer is if, instead of the above error message, I would get an indication that the passed value is null, with the rest of the format string rendered, perhaps like plain old printf in glibc:

[...] ptr=(null)

Is this achievable somehow? I would prefer not to add if-checks for such logging entries.

N.B.: After some digging around, I see that fmtlib has a fix for this, see fmtlib/fmt#226
However, the check is only included when using fmt::printf.

Thanks!

@gabime
Copy link
Owner

gabime commented Mar 3, 2019

@tomszilagyi Thanks for the update. Closing it.

@gabime gabime closed this as completed Mar 3, 2019
@watho
Copy link

watho commented Aug 29, 2019

Hello,

i still see the error on windows with spdlog 1.3.1. I don't understand the fmt-fix or what to do with that.

Simple test case:

const char* emtpy = nullptr;
SPDLOG_INFO("{}", empty);

@gabime
Copy link
Owner

gabime commented Aug 29, 2019

try casting to void* before passing it

@watho
Copy link

watho commented Aug 29, 2019

Thanks for the quick answer.

Casting it prints 0x0 for a null pointer (OK) but breaks printing the real value for non-null values. (not OK)

@gabime
Copy link
Owner

gabime commented Aug 29, 2019

oh, so you can try cast to string view instead: https://stackoverflow.com/a/47240730

@watho
Copy link

watho commented Aug 29, 2019

I'm pre c++17 and don't have std::string_view. I tried the bundled fmt::string_view but this gives an exception with a nullptr.

@tt4g
Copy link
Contributor

tt4g commented Aug 29, 2019

char* empty_chars = nullptr is not an empty characters. If accessed as a pointer, a segmentation fault will occur: https://wandbox.org/permlink/Uly1DGGrgQwVf30k

    char* nullptr_char = nullptr;

    std::cout << *nullptr_char << std::endl; // Segmentation fault

std::string also doesn't allow char* = nullptr: https://wandbox.org/permlink/txlM3YKji1EmVFpy

    char* nullptr_char = nullptr;
    
    std::string null_str(nullptr_char); // Abort
    
    std::cout << null_str << std::endl;

The empty characters is '\n': https://wandbox.org/permlink/cGF3hn330ARw8b5x

    char empty[] = { '\0' };

    char* empty_char = empty;
    std::cout << *empty_char << std::endl;

@watho
Copy link

watho commented Aug 29, 2019

I know this, but it does not matter. I am getting the null pointer from an external library. My request is the same like the original poster had:

What I would prefer is if, instead of the above error message, I would get an indication that the passed value is null, with the rest of the format string rendered, perhaps like plain old printf in glibc:
[...] ptr=(null)
Is this achievable somehow? I would prefer not to add if-checks for such logging entries.

My main problem is, that the error message does not include the original maybe unformatted message or filename and linenumber like my normal logs. So it is impossible to say where this error occurs.

My current workaround is to wrap all possible null pointer in something like SPDLOG_INFO({}, s ? s : "null"); and that is time-consuming and seems to be something the logging library should do.

bachittle pushed a commit to bachittle/spdlog that referenced this issue Dec 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants