Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > ridiculous warning or not?

Reply
Thread Tools

ridiculous warning or not?

 
 
Tim Rentsch
Guest
Posts: n/a
 
      12-17-2012
Keith Thompson <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
> [...]
>> I understand that you would like how the Standard is read to be
>> the same in comp.lang.c and comp.std.c. For now, though, let me
>> suggest that conversations about that are better in comp.std.c,
>> and for purposes of comp.lang.c it's better to read the Standard
>> how you think the committee reads it or expects it will be read.
>> Does that all make sense?

>
> Yes, more or less. In this particular case, though, there's a rule
> that's only stated in an example, and that IMHO is not supported
> by the normative text (though it could be with a small tweak).
> Furthermore, it's a rule that doesn't make a whole lot of sense
> to me. This raised, at least for me, a serious question about what
>
> int i[];
>
> as an external definition with no later completion of the type
> actually *means*, and whether it's even valid. It raises issues both
> about the text of the standard (clearly appropriate for comp.std.c),
> and about the semantics of the language defined by the standard
> (clearly appropriate for comp.lang.c).


Oh, that may be a difference between us. As far as I'm concerned,
what happens in this case is both defined enough and clear enough
(for purposes of comp.lang.c) so that there's no question about
what's supposed to happen. I agree that the Standard could do a
better job of expressing this, but not so much that anyone who
wants to understand what semantics are dictated is likely to be
misled. Let me ask it as a question: how likely is it (in your
opinion) that someone reading the Standard will reach a wrong
conclusion about what the behavior should be in such cases?
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      12-17-2012
Tim Rentsch <(E-Mail Removed)> writes:
> Keith Thompson <(E-Mail Removed)> writes:
>> Tim Rentsch <(E-Mail Removed)> writes:
>> [...]
>>> I understand that you would like how the Standard is read to be
>>> the same in comp.lang.c and comp.std.c. For now, though, let me
>>> suggest that conversations about that are better in comp.std.c,
>>> and for purposes of comp.lang.c it's better to read the Standard
>>> how you think the committee reads it or expects it will be read.
>>> Does that all make sense?

>>
>> Yes, more or less. In this particular case, though, there's a rule
>> that's only stated in an example, and that IMHO is not supported
>> by the normative text (though it could be with a small tweak).
>> Furthermore, it's a rule that doesn't make a whole lot of sense
>> to me. This raised, at least for me, a serious question about what
>>
>> int i[];
>>
>> as an external definition with no later completion of the type
>> actually *means*, and whether it's even valid. It raises issues both
>> about the text of the standard (clearly appropriate for comp.std.c),
>> and about the semantics of the language defined by the standard
>> (clearly appropriate for comp.lang.c).

>
> Oh, that may be a difference between us. As far as I'm concerned,
> what happens in this case is both defined enough and clear enough
> (for purposes of comp.lang.c) so that there's no question about
> what's supposed to happen. I agree that the Standard could do a
> better job of expressing this, but not so much that anyone who
> wants to understand what semantics are dictated is likely to be
> misled. Let me ask it as a question: how likely is it (in your
> opinion) that someone reading the Standard will reach a wrong
> conclusion about what the behavior should be in such cases?


Very likely, IMHO.

The wording in question is N1570 6.9.2p5, a non-normative example:

EXAMPLE 2 If at the end of the translation unit containing

int i[];

the array i still has incomplete type, the implicit initializer
causes it to have one element, which is set to zero on program
startup.

In the absence of that example, it would never have occurred to me that
the array i has one element. If I thought about it, I'd probably
conclude that it's equivalent to

int i[] = 0;

("with an initializer equal to 0", 6.9.2p2), and therefore a constraint
violation, or at least undefined behavior.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      12-20-2012
Keith Thompson <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>> Keith Thompson <(E-Mail Removed)> writes:
>>> Tim Rentsch <(E-Mail Removed)> writes:
>>> [...]
>>>> I understand that you would like how the Standard is read to be
>>>> the same in comp.lang.c and comp.std.c. For now, though, let me
>>>> suggest that conversations about that are better in comp.std.c,
>>>> and for purposes of comp.lang.c it's better to read the Standard
>>>> how you think the committee reads it or expects it will be read.
>>>> Does that all make sense?
>>>
>>> Yes, more or less. In this particular case, though, there's a rule
>>> that's only stated in an example, and that IMHO is not supported
>>> by the normative text (though it could be with a small tweak).
>>> Furthermore, it's a rule that doesn't make a whole lot of sense
>>> to me. This raised, at least for me, a serious question about what
>>>
>>> int i[];
>>>
>>> as an external definition with no later completion of the type
>>> actually *means*, and whether it's even valid. It raises issues both
>>> about the text of the standard (clearly appropriate for comp.std.c),
>>> and about the semantics of the language defined by the standard
>>> (clearly appropriate for comp.lang.c).

>>
>> Oh, that may be a difference between us. As far as I'm concerned,
>> what happens in this case is both defined enough and clear enough
>> (for purposes of comp.lang.c) so that there's no question about
>> what's supposed to happen. I agree that the Standard could do a
>> better job of expressing this, but not so much that anyone who
>> wants to understand what semantics are dictated is likely to be
>> misled. Let me ask it as a question: how likely is it (in your
>> opinion) that someone reading the Standard will reach a wrong
>> conclusion about what the behavior should be in such cases?

>
> Very likely, IMHO.
>
> The wording in question is N1570 6.9.2p5, a non-normative example:
>
> EXAMPLE 2 If at the end of the translation unit containing
>
> int i[];
>
> the array i still has incomplete type, the implicit initializer
> causes it to have one element, which is set to zero on program
> startup.
>
> In the absence of that example, it would never have occurred to me that
> the array i has one element. [snip elaboration]


Yes but the example is there! That's really the point of
what I'm saying: given that the example _is_ there, I think
it's highly unlikely that anyone will be misled about what
the Standard expects should happen. Right? Or do you think
they won't notice or won't understand the example?
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-21-2012
Tim Rentsch <(E-Mail Removed)> writes:
> Keith Thompson <(E-Mail Removed)> writes:
>> Tim Rentsch <(E-Mail Removed)> writes:
>>> Keith Thompson <(E-Mail Removed)> writes:
>>>> Tim Rentsch <(E-Mail Removed)> writes:
>>>> [...]
>>>>> I understand that you would like how the Standard is read to be
>>>>> the same in comp.lang.c and comp.std.c. For now, though, let me
>>>>> suggest that conversations about that are better in comp.std.c,
>>>>> and for purposes of comp.lang.c it's better to read the Standard
>>>>> how you think the committee reads it or expects it will be read.
>>>>> Does that all make sense?
>>>>
>>>> Yes, more or less. In this particular case, though, there's a rule
>>>> that's only stated in an example, and that IMHO is not supported
>>>> by the normative text (though it could be with a small tweak).
>>>> Furthermore, it's a rule that doesn't make a whole lot of sense
>>>> to me. This raised, at least for me, a serious question about what
>>>>
>>>> int i[];
>>>>
>>>> as an external definition with no later completion of the type
>>>> actually *means*, and whether it's even valid. It raises issues both
>>>> about the text of the standard (clearly appropriate for comp.std.c),
>>>> and about the semantics of the language defined by the standard
>>>> (clearly appropriate for comp.lang.c).
>>>
>>> Oh, that may be a difference between us. As far as I'm concerned,
>>> what happens in this case is both defined enough and clear enough
>>> (for purposes of comp.lang.c) so that there's no question about
>>> what's supposed to happen. I agree that the Standard could do a
>>> better job of expressing this, but not so much that anyone who
>>> wants to understand what semantics are dictated is likely to be
>>> misled. Let me ask it as a question: how likely is it (in your
>>> opinion) that someone reading the Standard will reach a wrong
>>> conclusion about what the behavior should be in such cases?

>>
>> Very likely, IMHO.
>>
>> The wording in question is N1570 6.9.2p5, a non-normative example:
>>
>> EXAMPLE 2 If at the end of the translation unit containing
>>
>> int i[];
>>
>> the array i still has incomplete type, the implicit initializer
>> causes it to have one element, which is set to zero on program
>> startup.
>>
>> In the absence of that example, it would never have occurred to me that
>> the array i has one element. [snip elaboration]

>
> Yes but the example is there! That's really the point of
> what I'm saying: given that the example _is_ there, I think
> it's highly unlikely that anyone will be misled about what
> the Standard expects should happen. Right? Or do you think
> they won't notice or won't understand the example?


Sure, the example is clear enough.

I just don't think that the assertion in the example follows,
or *should* follow, from the normative text. And I wouldn't want
to rely on what it says, both because if I want a 1-element array
it's easy enough to replace "[]" by "[1]", and because I wouldn't be
astonished if some compiler, following just the normative wording,
didn't implement it that way.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      12-21-2012
Keith Thompson <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>> Keith Thompson <(E-Mail Removed)> writes:
>>> Tim Rentsch <(E-Mail Removed)> writes:
>>>> Keith Thompson <(E-Mail Removed)> writes:
>>>>> Tim Rentsch <(E-Mail Removed)> writes:
>>>>> [...]
>>>>>> I understand that you would like how the Standard is read to be
>>>>>> the same in comp.lang.c and comp.std.c. For now, though, let me
>>>>>> suggest that conversations about that are better in comp.std.c,
>>>>>> and for purposes of comp.lang.c it's better to read the Standard
>>>>>> how you think the committee reads it or expects it will be read.
>>>>>> Does that all make sense?
>>>>>
>>>>> Yes, more or less. In this particular case, though, there's a rule
>>>>> that's only stated in an example, and that IMHO is not supported
>>>>> by the normative text (though it could be with a small tweak).
>>>>> Furthermore, it's a rule that doesn't make a whole lot of sense
>>>>> to me. This raised, at least for me, a serious question about what
>>>>>
>>>>> int i[];
>>>>>
>>>>> as an external definition with no later completion of the type
>>>>> actually *means*, and whether it's even valid. It raises issues both
>>>>> about the text of the standard (clearly appropriate for comp.std.c),
>>>>> and about the semantics of the language defined by the standard
>>>>> (clearly appropriate for comp.lang.c).
>>>>
>>>> Oh, that may be a difference between us. As far as I'm concerned,
>>>> what happens in this case is both defined enough and clear enough
>>>> (for purposes of comp.lang.c) so that there's no question about
>>>> what's supposed to happen. I agree that the Standard could do a
>>>> better job of expressing this, but not so much that anyone who
>>>> wants to understand what semantics are dictated is likely to be
>>>> misled. Let me ask it as a question: how likely is it (in your
>>>> opinion) that someone reading the Standard will reach a wrong
>>>> conclusion about what the behavior should be in such cases?
>>>
>>> Very likely, IMHO.
>>>
>>> The wording in question is N1570 6.9.2p5, a non-normative example:
>>>
>>> EXAMPLE 2 If at the end of the translation unit containing
>>>
>>> int i[];
>>>
>>> the array i still has incomplete type, the implicit initializer
>>> causes it to have one element, which is set to zero on program
>>> startup.
>>>
>>> In the absence of that example, it would never have occurred to me that
>>> the array i has one element. [snip elaboration]

>>
>> Yes but the example is there! That's really the point of
>> what I'm saying: given that the example _is_ there, I think
>> it's highly unlikely that anyone will be misled about what
>> the Standard expects should happen. Right? Or do you think
>> they won't notice or won't understand the example?

>
> Sure, the example is clear enough.
>
> I just don't think that the assertion in the example follows,
> or *should* follow, from the normative text. And I wouldn't want
> to rely on what it says, both because if I want a 1-element array
> it's easy enough to replace "[]" by "[1]", and because I wouldn't be
> astonished if some compiler, following just the normative wording,
> didn't implement it that way.


As I understand your objection, writing [1] wouldn't help. I think
your point is that the closest reading of 6.9.2 p2 would take "with an
initializer equal to 0" to mean "= 0", but both

int x[] = 0;

and

int x[1] = 0;

are equally invalid. Such a reading would make all un-initialised
file-scope declarations of array and struct objects invalid.

This is based on an old thread you posted in comp.std.c, so maybe I've
missed some more recent postings that makes the wording of 6.9.2 p2
problematic only in more limited circumstances.

--
Ben.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      12-21-2012
Keith Thompson <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>> Keith Thompson <(E-Mail Removed)> writes:
>>> Tim Rentsch <(E-Mail Removed)> writes:
>>>> Keith Thompson <(E-Mail Removed)> writes:
>>>>> Tim Rentsch <(E-Mail Removed)> writes:
>>>>> [...]
>>>>>> I understand that you would like how the Standard is read to be
>>>>>> the same in comp.lang.c and comp.std.c. For now, though, let me
>>>>>> suggest that conversations about that are better in comp.std.c,
>>>>>> and for purposes of comp.lang.c it's better to read the Standard
>>>>>> how you think the committee reads it or expects it will be read.
>>>>>> Does that all make sense?
>>>>>
>>>>> Yes, more or less. In this particular case, though, there's a rule
>>>>> that's only stated in an example, and that IMHO is not supported
>>>>> by the normative text (though it could be with a small tweak).
>>>>> Furthermore, it's a rule that doesn't make a whole lot of sense
>>>>> to me. This raised, at least for me, a serious question about what
>>>>>
>>>>> int i[];
>>>>>
>>>>> as an external definition with no later completion of the type
>>>>> actually *means*, and whether it's even valid. It raises issues both
>>>>> about the text of the standard (clearly appropriate for comp.std.c),
>>>>> and about the semantics of the language defined by the standard
>>>>> (clearly appropriate for comp.lang.c).
>>>>
>>>> Oh, that may be a difference between us. As far as I'm concerned,
>>>> what happens in this case is both defined enough and clear enough
>>>> (for purposes of comp.lang.c) so that there's no question about
>>>> what's supposed to happen. I agree that the Standard could do a
>>>> better job of expressing this, but not so much that anyone who
>>>> wants to understand what semantics are dictated is likely to be
>>>> misled. Let me ask it as a question: how likely is it (in your
>>>> opinion) that someone reading the Standard will reach a wrong
>>>> conclusion about what the behavior should be in such cases?
>>>
>>> Very likely, IMHO.
>>>
>>> The wording in question is N1570 6.9.2p5, a non-normative example:
>>>
>>> EXAMPLE 2 If at the end of the translation unit containing
>>>
>>> int i[];
>>>
>>> the array i still has incomplete type, the implicit initializer
>>> causes it to have one element, which is set to zero on program
>>> startup.
>>>
>>> In the absence of that example, it would never have occurred to me that
>>> the array i has one element. [snip elaboration]

>>
>> Yes but the example is there! That's really the point of
>> what I'm saying: given that the example _is_ there, I think
>> it's highly unlikely that anyone will be misled about what
>> the Standard expects should happen. Right? Or do you think
>> they won't notice or won't understand the example?

>
> Sure, the example is clear enough.
>
> I just don't think that the assertion in the example follows,
> or *should* follow, from the normative text. And I wouldn't want
> to rely on what it says, both because if I want a 1-element array
> it's easy enough to replace "[]" by "[1]", and because I wouldn't be
> astonished if some compiler, following just the normative wording,
> didn't implement it that way.


That's a difference between us - I /would/ be astonished if any
implementation got this wrong. (That doesn't mean I would try to
convince you you shouldn't be astonished, only that my reaction
is different.)

But more important, I think my original point stands: there is
no confusion about what to tell aspiring C developers, so the
issues here are better suited for comp.std.c than comp.lang.c.
If you still disagree with that I'm unclear as to why.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
*RANT* Ridiculous EDA software "user license agreements"? license_rant_master VHDL 37 04-29-2005 03:48 PM
Ridiculous readInt() bug? Read-head not advancing far enough? nobrow@eircom.net Java 17 04-15-2005 10:12 AM
ridiculous - javax.swing.text.html.HTMLEditorKit.Parser needs X11 server to work Nebojsa Topolscak Java 3 01-14-2005 10:43 PM
Rather ridiculous/OT but Im sharing this :p Rob HTML 6 12-18-2003 10:46 PM
This is ridiculous...I AM THE Ron Williams!! R.J. Williams MCSE 33 08-16-2003 10:15 AM



Advertisments