-
Notifications
You must be signed in to change notification settings - Fork 601
Compile S_emulate_langinfo() everywhere where needed #21903
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
Conversation
| * nothing on the more typical case where all possible categories present on | ||
| * the platform are handled. */ | ||
| # ifdef HAS_IGNORED_LOCALE_CATEGORIES_ | ||
| # if defined(HAS_IGNORED_LOCALE_CATEGORIES_) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Point of information for a non-C programmer: Is there a difference between this syntax:
# ifdef SOMETHING
and this syntax:
# if defined(SOMETHING)
Why do you use one or the other?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#ifdef can only deal with one singe symbol
#if defined(FOO) is equal to #ifdef FOO, but when testing on more than one single symbol, like in this code, the second syntax is required
#if defined(FOO) || defined(BAR) does not have an #ifdef variant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#ifdef FOO is subsumed by the form #if defined FOO (or equivalently, #if defined ( FOO )). As for why both forms exist, I believe #ifdef (and #ifndef) came first historically and defined was added later when people needed more complex conditionals.
Choosing between them is mostly a matter of taste (personally I don't like the extra parentheses in the defined (FOO) form, for example). Some purists argue that you should limit yourself to #ifdef because anything more complex than that is a sign that you're abusing the preprocessor for things it was never meant to do (and you should presumably move complex configuration logic to a separate stage that emits simple macro definitions). In perl, that train has sailed.
So use 0 instead; 1 instead of 'true'
The next commit will want this header's information to be available for perl_langinfo.h.
This will not compile if -DNO_LOCALE is specified, as well as some other Configurations where various locale categories are missing or confined to be the C locale.
02c9456 to
5afaaf1
Compare
|
As reported in #21909 (comment), the 3 commits in this pull request resolve the build-time failure reported in #21909 but generate 3 new build-time warnings. (The commit IDs below are from my local research branch.) From the output of So we should eliminate these new build-time warnings before merging this branch to blead. Once the warnings are gone, the p.r. should be reviewed to see if it meets its own objectives and if the C-level code is correct. |
|
#21892 eliminates these warnings, in conjunction with this PR |
I continued with the QA procedure I described in #21909 (comment). I started with the investigative branch I described in that ticket and merged #21892 into it. I then configured and built twice, first with my regular (Linux) configuration switches, then adding Since we've been juggling quite a few locale-related pull requests lately, I recommend we get final review on this p.r. and #21892 (i.e., review by someone other than me), merge them into blead, and only then look to review additional p.r.s. |
Prior to this series of commits, this function was not getting compiled in some Configurations where it was needed, and not getting called always when needed.