Groups | Search | Server Info | Login | Register
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.std.c |
| Subject | Re: int n = {{0}}; |
| Date | 2024-01-18 17:52 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <86jzo6jdic.fsf@linuxsc.com> (permalink) |
| References | <8734xwkc1c.fsf@nosuchdomain.example.com> <86cyvnw0n4.fsf@linuxsc.com> <878r6b3q0o.fsf@nosuchdomain.example.com> |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Citations are from N1570 (C11 draft). I don't think there are any
>>> relevant differences in other editions or drafts of the standard.
>>>
>>> Quick summary: Why is
>>> int n = {{0}};
>>> undefined behavior rather than a constraint violation?
>>
>> Because there is no practical benefit to changing what the
>> standard says now.
>
> Do you have an opinion about whether it should have been specified as a
> constraint violation rather than undefined behavior in the first place?
I don't have any pertinent information on which to base such an
opinion. It's possible there was existing code that prompted
what decision was made at the time. It's also possible that what
was done is just the result of an oversight. I'm inclined to think
that there was some reasoning that led to what was actually done
(ie, that there is undefined behavior but no constraint violation),
but that's just a general impression, not based on any specific
facts. If there was such reasoning, then without more information
I would tend to favor supporting it.
I guess I could add that there are other constructions in C that
are undefined behavior, and are identifiable at compile time, but
which are not constraint violations, and I think that's the right
decision for at least some of them.
>> There's no practical benefit to changing it. The current rule
>> has been in place since the original ANSI C standard, more than
>> 30 years ago. Whatever the motivation may have been at that
>> time, there is no incentive to change the rules now; compilers
>> already give diagnostics in such cases, even though they don't
>> have to. Changing the rules would mean throwing away a degree
>> of freedom with no significant benefit.
>
> It would remove a degree of freedom for implementers, one that
> few if any currently take advantage of.
As I mentioned in my earlier post, the clang compiler does take
advantage of this particular degree of freedom, with an option to
turn off diagnostics corresponding to such cases.
> Meaningless degrees of freedom for implementers do not help
> users.
I infer from the existence of the clang option that some people
think the degree of freedom here is both meaningful and useful.
Back to comp.std.c | Previous | Next — Previous in thread | Find similar
int n = {{0}}; Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-26 19:57 -0700
Re: int n = {{0}}; Richard Damon <Richard@Damon-Family.org> - 2023-10-28 09:41 -0700
Re: int n = {{0}}; Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-03 11:23 -0800
Re: int n = {{0}}; Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-03 14:00 -0800
Re: int n = {{0}}; Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-18 17:52 -0800
csiph-web