Skip to content

make level_enum from_str() case insensitive #3525#3531

Closed
neundorf wants to merge 1 commit intogabime:v1.xfrom
neundorf:CaseInsensitiveFromStr
Closed

make level_enum from_str() case insensitive #3525#3531
neundorf wants to merge 1 commit intogabime:v1.xfrom
neundorf:CaseInsensitiveFromStr

Conversation

@neundorf
Copy link

This patch changes the behaviour of from_str() so that the level names are compared case-insensitive.
This has the side effect of making load_levels() work if the names were set to UPPER oder CamelCase in tweakme.h.

Beside that, now also the special cases for "off", "err" and "warn" now check that the names are actually "off", "error" and "warning" and have not been set to something else.
It would be strange behaviour if I would set the name of the error level e.g. to "Fehler" and spdlog would recognize "fehler" and also "err", but not "error" as that level.

The test also checks a mixed case string now, and also "err".

@neundorf
Copy link
Author

@gabime This patch makes from_str() case-insensitive.
I'm not sure why the builds here in CI failed initially, it was building for me.
As far as I can see it was related to #ifndef SPDLOG_HEADER_ONLY. I looked around, and I didn't find the cmake option to turn this on and off. How do I ?

@tt4g
Copy link
Contributor

tt4g commented Jan 26, 2026

IMO.

Common symbols used in spdlog are defined in common.h. You should not use cfg/helpers.h in this header file. It may be better to move the lowercase API to common.h.

Another way: Since to_lower_() is only used in cfg/helpers-inl.h, it may be possible to define it without external linkage in common-inl.h (move function).

This patch changes the behaviour of from_str() so that the level
names are compared case-insensitive.
This has the side effect of making load_levels() work if the names
were set to UPPER oder CamelCase in tweakme.h.

Beside that, now also the special cases for "off", "err" and "warn"
now check that the names are actually "off", "error" and "warning"
and have not been set to something else.
It would be strange behaviour if I would set the name of the error
level e.g. to "Fehler" and spdlog would recognize "fehler" and
also "err", but not "error" as that level.

The test also checks a mixed case string now, and also "err".
@neundorf neundorf force-pushed the CaseInsensitiveFromStr branch from 7e1f05e to d490998 Compare January 26, 2026 19:55
@neundorf
Copy link
Author

@tt4g what do you think about my current version ?

@tt4g
Copy link
Contributor

tt4g commented Jan 27, 2026

@neundorf I'm concerned that the to_lower() API declaration is missing in common.h.

EDIT: This API might be reused in other spdlog code, so it might be better to have a declaration.

@neundorf
Copy link
Author

Hmm, to_lower() is currently only used locally in strings_equal_ci(),which is in common.h.
I don't see a strong reason to make to_lower() "public" right now. It also wasn't public before.

@tt4g
Copy link
Contributor

tt4g commented Jan 28, 2026

Yes. Whether to export to_lower() in common.h is a matter of personal preference.
Therefore, whether we should change it depends on what @gabime thinks.

#if __cplusplus >= 201703L
constexpr
#endif
SPDLOG_API char to_lower(char ch) {
Copy link
Owner

@gabime gabime Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why SPDLOG_API. I would expect SPDLOG_INLINE

//
// Returns true if two strings are equal, case-insensitive
//
SPDLOG_API bool strings_equal_ci(string_view_t s1, string_view_t s2);
Copy link
Owner

@gabime gabime Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why SPDLOG_API ? i would expect SPDLOG_INLINE

Copy link
Author

@neundorf neundorf Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can change that, no problem.

But if I didn't mix things up, there is a second merge request for the same issue:
#3535

If you prefer the other one, I wouldn't put more work into my merge request.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure yet. The other merge seems bit leaner indeed

@gabime
Copy link
Owner

gabime commented Feb 9, 2026

I merged #3535 instead. Thanks anyway @neundorf !

@gabime gabime closed this Feb 9, 2026
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

Successfully merging this pull request may close these issues.

3 participants