joerg added a comment.

In, @jyknight wrote:

> In, @joerg wrote:
> > (2) It adds magic behavior that can make debugging more difficult. 
> > Partially preprocessed sources for example could be compiled with plain -c 
> > before, now they need a different command line.
> If this is a problem, making it be Linux-only does _nothing_ to solve it. But 
> I don't actually see how this is a substantively new problem? Compiling with 
> plain -c before
>  would get #defines for those predefined macros that the compiler sets, even 
> though you may not have wanted those. Is this fundamentally different?

It makes it a linux-only problem. As such, it is something *I* only care about 
secondary. A typical use case I care about a lot is pulling the crash report 
sources from my (NetBSD) build machine,
extracting the original command line to rerun the normal compilation with 
-save-temps. I don't necessarily have the (same) system headers on the machine 
I use for debugging and that's exactly
the kind of use case this change breaks. All other predefined macros are driven 
by the target triple and remain stable.

>> (3) It seems to me that the GNU userland (and maybe Windows) is the 
>> exception to a well integrated tool chain. Most other platforms have a 
>> single canonical
>>  libc, libm and libpthread implementation and can as such directly define 
>> all the relevant macros directly in the driver.
> I don't think this is accurate. There's many platforms out there, and for 
> almost none of them do we have exact knowledge of the features of the libc 
> encoded
>  into the compiler. I'd note that not only do you need this for every (OS, 
> libc) combination, you'd need it for every (OS, libc-VERSION) combination.

Not really. The feature set is rarely changing and generally will have only a 
cut-off version.

>> Given that many of the macros involved are already reflected by the compiler 
>> behavior anyway, they can't be decoupled. I.e. the questionable
>>  concept of locale-independent wchar_t is already hard-coded in the front 
>> end as soon as any long character literals are used.
> AFAICT, this example is not actually the case. The frontend only needs to 
> know *a* valid encoding for wide-character literals in some
>  implementation-defined locale (for example, it might always emit them as 
> unicode codepoints, as clang does).  Standard says:
>  "the array elements [...] are initialized with the sequence of wide 
> characters corresponding to the multibyte character sequence, as
>  defined by the mbstowcs function with an implementation defined current 
> locale."

I know what the standard says. It doesn't make much sense if you do not have a 
fixed wchar_t encoding.

> On the other hand, I believe the intent of this macro is to guarantee that 
> _no matter what_ the locale is,
>  that a U+0100 character (say, translated with mbrtowc from the locale 
> encoding) gets represented as 0x100.

Yes, so it is essentially "we have screwed up by creating a language mechanism 
that adds a major constraint, so let's go all the way".

> Thus, it's "fine" for the frontend to always emit wchar_t literals as 
> unicode, yet, the libc may sometimes use an arbitrary different
>  internal encoding, depending on the locale used at runtime. (Obviously using 
> wide character literals with such a libc would be a poor 
>  user experience, and such a libc probably ought to reconsider its choices, 
> but that's a different discussion.)

One of the biggest opponents of that was Itojun. It's not a decision that 
should be made here as it is only indirectly related to this discussion.

>> As such, please move the command line additions back into the 
>> target-specific files for targets that actually want to get this behavior.
> Without even a suggestion of a better solution to use for other targets, I 
> find it is to be a real shame to push for this to be linux-only,
>  and leave everyone else hanging. I find that that _most_ of these defines 
> are effectively library decisions. I further would claim that these
>  are likely to vary over the lifetime of even a single libc, and that as such 
> we would be better served by allowing the libc to set them directly, rather 
> than encoding it into the compiler.
> TTBOMK, no targets except linux/glibc/gcc actually comply with this part of 
> the C99/C11 standard today, and so this feature would be useful to have 
> available across all targets.
> (I very much dislike that the C standard has started adding all these new 
> predefined macros, instead of exposing them from a header, but there's not 
> much to be done about that...)

Exactly. It's not like this is a lot of target logic. It should be a single 
call for targets that want to get this functionality. But that's my point -- it 
should be opt-in, not opt-out.

cfe-commits mailing list

Reply via email to