Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #24635 > unrolled thread

ridiculous warning or not?

Back to article view | Back to comp.lang.c

Contents

  ridiculous warning or not? kerravon <kerravon@w3.to> - 2012-08-20 02:41 -0700
    Re: ridiculous warning or not? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-20 07:55 -0400
    Re: ridiculous warning or not? army1987 <army1987@ask-for-it.invalid> - 2012-08-20 19:11 +0000
    Re: ridiculous warning or not? Kenneth Brody <kenbrody@spamcop.net> - 2012-08-20 16:09 -0400
      Re: ridiculous warning or not? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 07:29 -0700
    Re: ridiculous warning or not? Andrew Cooper <amc96@cam.ac.uk> - 2012-08-21 00:36 +0100
    Re: ridiculous warning or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-21 01:41 +0100
      Re: ridiculous warning or not? Keith Thompson <kst-u@mib.org> - 2012-08-20 18:59 -0700
        Re: ridiculous warning or not? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 08:03 -0700
          Re: ridiculous warning or not? Keith Thompson <kst-u@mib.org> - 2012-09-07 14:37 -0700
            Re: ridiculous warning or not? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 19:17 -0700
              Re: ridiculous warning or not? Keith Thompson <kst-u@mib.org> - 2012-09-07 19:56 -0700
                Re: ridiculous warning or not? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-08 06:30 -0700
      Re: ridiculous warning or not? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 07:57 -0700
        Re: ridiculous warning or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 00:25 +0100
          Re: ridiculous warning or not? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 18:58 -0700
            Re: ridiculous warning or not? Keith Thompson <kst-u@mib.org> - 2012-09-07 19:26 -0700
              Re: ridiculous warning or not? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-08 06:26 -0700
                Re: ridiculous warning or not? Keith Thompson <kst-u@mib.org> - 2012-09-08 11:33 -0700
                  Re: ridiculous warning or not? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 14:39 -0800
                    Re: ridiculous warning or not? Keith Thompson <kst-u@mib.org> - 2012-12-17 15:56 -0800
                      Re: ridiculous warning or not? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-20 10:31 -0800
                        Re: ridiculous warning or not? Keith Thompson <kst-u@mib.org> - 2012-12-20 16:57 -0800
                          Re: ridiculous warning or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-21 03:11 +0000
                          Re: ridiculous warning or not? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-21 09:06 -0800
            Re: ridiculous warning or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 03:42 +0100
              Re: ridiculous warning or not? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-08 06:01 -0700
                Re: ridiculous warning or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 14:45 +0100
                  Re: ridiculous warning or not? Keith Thompson <kst-u@mib.org> - 2012-09-08 11:28 -0700
                    Re: ridiculous warning or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 22:53 +0100
    Re: ridiculous warning or not? kerravon <kerravon@w3.to> - 2012-08-21 03:25 -0700
      Re: ridiculous warning or not? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-21 11:20 -0700
        Re: ridiculous warning or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-21 21:07 +0100
          Re: ridiculous warning or not? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-21 14:39 -0700
            Re: ridiculous warning or not? Ike Naar <ike@iceland.freeshell.org> - 2012-08-21 22:09 +0000
              Re: ridiculous warning or not? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-21 15:13 -0700
                Re: ridiculous warning or not? Fred K <fred.l.kleinschmidt@gmail.com> - 2012-08-22 07:17 -0700

Page 2 of 2 — ← Prev page 1 [2]

#29444

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> 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) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#29535

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> 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?

[toc] | [prev] | [next] | [standalone]

#29560

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> Tim Rentsch <txr@alumni.caltech.edu> 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) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#29564

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>> Tim Rentsch <txr@alumni.caltech.edu> 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.

[toc] | [prev] | [next] | [standalone]

#29569

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>> Tim Rentsch <txr@alumni.caltech.edu> 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.

[toc] | [prev] | [next] | [standalone]

#26121

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> [...snipped a lot, rearranged...]
>>
>> A misunderstanding -- I use that style all the time.
>>
>>> Incidentally, a similar pattern is legal with struct's (or union's):
>>
>> The same misunderstanding.  
>
> Okay, all good..
>
>> The thing I could see no sensible reason for writing was what
>> OP wrote: a tentative definition and nothing else.  Explicitly
>> completing something later is very natural.  Having it be
>> completed automatically is, to me, a little odd.
>
> Probably I can imagine a scenario where havinng a default size
> of one element would be useful.  But it's easier to imagine
> a scenario where having an option for a compiler warning is
> more useful. :)
>
>
>>> The default semantics of there nominally being one element
>>> is, I would guess, simply a consequence of the default
>>> initialization rules.
>>
>> I don't quite see that.  That the value should be zero, yes,
>> but why does it follow from them that there would be one
>> element in the array?  Leaving the definition alone and thus
>> making the object incomplete seems to be just as natural a way
>> to treat the situation.
>
> Ahh, because of the rule for how tentative definitions
> are defined, without regard to incompleteness.  Consider
> this, a tentative definition for a complete struct type:
>
>     struct xyz { ... } some_struct;  // tentative definition
>
>     ... no explicit defintion, hence ...
>
>     struct xyz some_struct = { 0 };  // this definition supplied implicitly
>
> Now apply that to a tentative definition for an array,
> but with the array having an incomplete type:
>
>     int some_array[];  // tentative
>
>     ... no explicit definition, hence ...
>
>     int some_array[] = { 0 };  // this definition supplied implicitly
>
> You see how the default sizing rule falls out of the rule
> for default initialization of objects tentatively defined
> but not explicitly defined?  That rule wasn't written with
> incomplete types in mind (I am guessing), but it has the
> effect of completing them in the case of incomplete arrays.

Right.  I get that.  What's bothering me is that I don't see these two
cases are comparable.  In the first, it makes no odds if there is an
implicit "={0};" or not.  In the second, it even alters the type!  If
the rule were just that multiple tentative definitions are permitted and
that the final type is the composite type, the rules for default
initialisation of file-scope objects would do the rest.  As far as I can
see, only arrays are altered by that final phrase "with an initializer
equal to zero".

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#26135

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [snip]
>> You see how the default sizing rule falls out of the rule
>> for default initialization of objects tentatively defined
>> but not explicitly defined?  That rule wasn't written with
>> incomplete types in mind (I am guessing), but it has the
>> effect of completing them in the case of incomplete arrays.
>
> Right.  I get that.  What's bothering me is that I don't see
> these two cases are comparable.  In the first, it makes no odds
> if there is an implicit "={0};" or not.  In the second, it even
> alters the type!  If the rule were just that multiple tentative
> definitions are permitted and that the final type is the
> composite type, the rules for default initialisation of
> file-scope objects would do the rest.  As far as I can see,
> only arrays are altered by that final phrase "with an
> initializer equal to zero".

Ahh, now I see what you were saying.

If you'll allow me to speculate...  way back when, as the
original standardization effort was under way in the late 1980's,
the rule for initializing tentative object definitions (in what
is now section 6.9.2) was done relatively early, with the wording
"with an initializer equal to 0", which appeared in C89/C90.  The
fixup for non-scalar types was done later (ie after the decision
about object defintions but still part of C89).  The wording from
the section on initialization (ie, in what is now 6.7.9 in C11)
that appeared in C89 is interesting:

    If an object that has static storage duration is not
    initialized explicitly, it is initialized implicitly as if
    every member that has arithmetic type were assigned 0 and
    every member that has pointer type were assigned a null
    pointer constant.

It's like they wrote the two rules independently:  one rule about
external object definitions that was written with scalar types in
mind, another rule in the section on initializers that was written
with non-scalar types in mind.  Possibly the two sections were
written independently, or mostly independently, each side roughly
filling in the holes of the other.  In any case, once the decision
about what to say for external object definitions was done, the
remaining passages were filled in focusing on non-scalar types,
and that ended up in the section on initialization.

Again, this is all speculation on my part.  I did take clues from
the C89/C90 text, and also from the Rationale (C99V5.10), so
it wasn't a completely uninformed guess.  More of a only very
mildly informed guess.  :)

[toc] | [prev] | [next] | [standalone]

#26139

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [snip]
>>> You see how the default sizing rule falls out of the rule
>>> for default initialization of objects tentatively defined
>>> but not explicitly defined?  That rule wasn't written with
>>> incomplete types in mind (I am guessing), but it has the
>>> effect of completing them in the case of incomplete arrays.
>>
>> Right.  I get that.  What's bothering me is that I don't see
>> these two cases are comparable.  In the first, it makes no odds
>> if there is an implicit "={0};" or not.  In the second, it even
>> alters the type!  If the rule were just that multiple tentative
>> definitions are permitted and that the final type is the
>> composite type, the rules for default initialisation of
>> file-scope objects would do the rest.  As far as I can see,
>> only arrays are altered by that final phrase "with an
>> initializer equal to zero".
>
> Ahh, now I see what you were saying.

I can see it would have been a struggle.  I did not express it well.

> If you'll allow me to speculate...  way back when, as the
> original standardization effort was under way in the late 1980's,
> the rule for initializing tentative object definitions (in what
> is now section 6.9.2) was done relatively early, with the wording
> "with an initializer equal to 0", which appeared in C89/C90.  The
> fixup for non-scalar types was done later (ie after the decision
> about object defintions but still part of C89).  The wording from
> the section on initialization (ie, in what is now 6.7.9 in C11)
> that appeared in C89 is interesting:
>
>     If an object that has static storage duration is not
>     initialized explicitly, it is initialized implicitly as if
>     every member that has arithmetic type were assigned 0 and
>     every member that has pointer type were assigned a null
>     pointer constant.
>
> It's like they wrote the two rules independently:  one rule about
> external object definitions that was written with scalar types in
> mind, another rule in the section on initializers that was written
> with non-scalar types in mind.  Possibly the two sections were
> written independently, or mostly independently, each side roughly
> filling in the holes of the other.  In any case, once the decision
> about what to say for external object definitions was done, the
> remaining passages were filled in focusing on non-scalar types,
> and that ended up in the section on initialization.
>
> Again, this is all speculation on my part.  I did take clues from
> the C89/C90 text, and also from the Rationale (C99V5.10), so
> it wasn't a completely uninformed guess.  More of a only very
> mildly informed guess.  :)

That sounds entirely plausible. If you'll permit my own speculation...
When I said "for historical reasons" I was thinking that it might be a
hang-over from B.  In B, arrays are indexed from 0 but the size is one
more than the constant used in the declaration:

  data[10];

makes an 11 elements array indexed from 0 to 10 inclusive.  Omitting the
constants is equivalent to writing zero, so

  data[];

makes data a 1-element array with a single valid index of 0.  Whether
this oddity ever got into early C and then ended up being formalised
because that's what some reference implementation did I don't know; I
accept that without that link it's all a bit tentative (boom, boom).

But your explanation has the merit of being rooted in the evolution of
the words in question.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#26147

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> That sounds entirely plausible. If you'll permit my own speculation...
> When I said "for historical reasons" I was thinking that it might be a
> hang-over from B.  In B, arrays are indexed from 0 but the size is one
> more than the constant used in the declaration:
>
>   data[10];
>
> makes an 11 elements array indexed from 0 to 10 inclusive.  Omitting the
> constants is equivalent to writing zero, so
>
>   data[];
>
> makes data a 1-element array with a single valid index of 0.  Whether
> this oddity ever got into early C and then ended up being formalised
> because that's what some reference implementation did I don't know; I
> accept that without that link it's all a bit tentative (boom, boom).

That doesn't appear to be the case for all versions of B.  I see
no such rule in <http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html>.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#26152

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> That sounds entirely plausible. If you'll permit my own speculation...
>> When I said "for historical reasons" I was thinking that it might be a
>> hang-over from B.  In B, arrays are indexed from 0 but the size is one
>> more than the constant used in the declaration:
>>
>>   data[10];
>>
>> makes an 11 elements array indexed from 0 to 10 inclusive.  Omitting the
>> constants is equivalent to writing zero, so
>>
>>   data[];
>>
>> makes data a 1-element array with a single valid index of 0.  Whether
>> this oddity ever got into early C and then ended up being formalised
>> because that's what some reference implementation did I don't know; I
>> accept that without that link it's all a bit tentative (boom, boom).
>
> That doesn't appear to be the case for all versions of B.  I see
> no such rule in <http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html>.

Curious.  Half the rule is there (the part about [] meaning [0]) but the
meaning of the constant in brackets is clearly different.  In my B
reference manual (for which I have no date) it says:

  "An external vector definition has one of the following forms:

     name [ ] ;
     name [ constant ] ;
     name [ ] ival , ival ... ;
     name [ constant ] ival , ival ... ;

  The name is initialized with the lvalue of the base of an external
  vector. If the vector size is missing, zero is assumed. In either
  case, the vector is initialized with the list of ivals (See 7.1). The
  actual size of the vector is the maximum of constant+1 and the number
  of initial values."

and the "Tutorial Introduction to the Language B" says:

  "We declare v external within the function (don't mention a size) by

      extrn v;

  and then outside all functions write

      v[10];

  External vectors may be initialized just as external simple variables:
  v[10] 'hi!', 1, 2, 3, 0777; sets v[0] to the character constant 'hi!',
  and V[1] through v[4] to various numbers. v[5] through v[10] are not
  initialized."

which confirms the indexing is from 0 to 10 inclusive.

By the way, this is not a "two references trumps one" post as each cites
the other and the reference manual calls the tutorial "part one of this
document" so it's really all one thing.

The lack of dates is annoying but even with dates there's no easy way to
know if this is change over time or just a oddity that varied between
implementations.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#24676

On Monday, August 20, 2012 7:41:21 PM UTC+10, kerravon wrote:
> I'll stop using that syntax if the compiler is
> more correct than me.

Wow, just wow. Thanks everyone for your responses.

I'll tell you a story. I normally don't have a
signature in my emails, but someone at work
complained that I was asking them to do things
and they had no idea who I was, and could I thus
include a signature.

The standard template for a signature includes a
job title. I'm a contractor so I didn't think I
had one, other than "contractor", so I just made
up "Junior C Programmer", since as I have stated
my whole career, my career goal is to have a title
of "Senior C Programmer", and I wanted to have
a goal to work towards. Note that I have been
programming in C since 1987. Also note that I have
written my own C runtime library for DOS/Windows/
Unix/OS2/MVS/CMS/VSE, which you can find here:

http://pdos.sourceforge.net

along with not one but two operating systems written
from scratch.

I also spent years getting GCC ported to MVS, CMS
and VSE, which were the very last commercial
programming environments that didn't have a free,
or standard, C compiler. You can find that here:

http://gccmvs.sourceforge.net

But despite all that, it took about 10 minutes for
comp.lang.c to (correctly) point out that the title
of "Junior C Programmer" was probably the right thing
to run with. I later found out (from Lync status
reported by others), that I actually do have an
official title, which is "Senior Software Engineer",
so I updated my title to that, but in spirit, I'm
still learning C. I actually bought the ISO C90
standard (or its AS3955-1991 equivalent), and it
really is a beautiful document, but I've never
read it cover to cover yet, so the title of "Junior"
is well-deserved.

I thought that int **x was the same as int *x[]
anywhere, but your pointed questions made me realise
just how messed up my thinking was (despite my
high (misplaced) confidence that I was right and
the compiler was being ridiculous).

Thanks.  Paul.

[toc] | [prev] | [next] | [standalone]

#24679

On Tuesday, August 21, 2012 6:25:29 PM UTC+8, kerravon wrote:
> On Monday, August 20, 2012 7:41:21 PM UTC+10, kerravon wrote:
> 
> > I'll stop using that syntax if the compiler is
> 
> > more correct than me.
> 
> 
> 
> Wow, just wow. Thanks everyone for your responses.
> 
> 
> 
> I'll tell you a story. I normally don't have a
> 
> signature in my emails, but someone at work
> 
> complained that I was asking them to do things
> 
> and they had no idea who I was, and could I thus
> 
> include a signature.
> 
> 
> 
> The standard template for a signature includes a
> 
> job title. I'm a contractor so I didn't think I
> 
> had one, other than "contractor", so I just made
> 
> up "Junior C Programmer", since as I have stated
> 
> my whole career, my career goal is to have a title
> 
> of "Senior C Programmer", and I wanted to have
> 
> a goal to work towards. Note that I have been
> 
> programming in C since 1987. Also note that I have
> 
> written my own C runtime library for DOS/Windows/
> 
> Unix/OS2/MVS/CMS/VSE, which you can find here:
> 
> 
> 
> http://pdos.sourceforge.net
> 
> 
> 
> along with not one but two operating systems written
> 
> from scratch.
> 
> 
> 
> I also spent years getting GCC ported to MVS, CMS
> 
> and VSE, which were the very last commercial
> 
> programming environments that didn't have a free,
> 
> or standard, C compiler. You can find that here:
> 
> 
> 
> http://gccmvs.sourceforge.net
> 
> 
> 
> But despite all that, it took about 10 minutes for
> 
> comp.lang.c to (correctly) point out that the title
> 
> of "Junior C Programmer" was probably the right thing
> 
> to run with. I later found out (from Lync status
> 
> reported by others), that I actually do have an
> 
> official title, which is "Senior Software Engineer",
> 
> so I updated my title to that, but in spirit, I'm
> 
> still learning C. I actually bought the ISO C90
> 
> standard (or its AS3955-1991 equivalent), and it
> 
> really is a beautiful document, but I've never
> 
> read it cover to cover yet, so the title of "Junior"
> 
> is well-deserved.
> 
> 
> 
> I thought that int **x was the same as int *x[]
> 
> anywhere, but your pointed questions made me realise
> 
> just how messed up my thinking was (despite my
> 
> high (misplaced) confidence that I was right and
> 
> the compiler was being ridiculous).
> 
> 
> 
> Thanks.  Paul.

int **x ; // a pointer to a pointer of an integer
int* x2[4000]; // an array of 4000 pointers to integers in the heap?
int i,j; //i-n for ineger idexing

// malloc might fail

for(j=0;j<4000;j++)
  if ((  x2[j]=malloc(4000* sizeof(int *))) ==NULL)
    {i=-1; break; }

if (i==-1) 
{ //error trapping here ....}

//x2[j][i] of 4000X4000 integers here can be used

x=x2 ; // an alias of x2


Can you get the difference?

[toc] | [prev] | [next] | [standalone]

#24682

88888 Dihedral <dihedral88888@googlemail.com> writes:
<snip>
> int **x ; // a pointer to a pointer of an integer
> int* x2[4000]; // an array of 4000 pointers to integers in the heap?
> int i,j; //i-n for ineger idexing
>
> // malloc might fail
>
> for(j=0;j<4000;j++)
>   if ((  x2[j]=malloc(4000* sizeof(int *))) ==NULL)

Wrong type in the malloc call.  Using the often quoted idiom here would
have prevented this problem:

   x2[j] = malloc(4000 * sizeof *x2[j])

>     {i=-1; break; }
>
> if (i==-1) 
> { //error trapping here ....}

i may be -1 even without any error.

> //x2[j][i] of 4000X4000 integers here can be used
>
> x=x2 ; // an alias of x2
>
> Can you get the difference?

Do you mean that they behave differently as operands of sizeof and of &?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#24690

On Wednesday, August 22, 2012 4:07:24 AM UTC+8, Ben Bacarisse wrote:
> 88888 Dihedral <dihedral88888@googlemail.com> writes:
> 
> <snip>
> 
> > int **x ; // a pointer to a pointer of an integer
> 
> > int* x2[4000]; // an array of 4000 pointers to integers in the heap?
> 
> > int i,j; //i-n for ineger idexing
> 
> >
> 
> > // malloc might fail
> 
> >
> 
> > for(j=0;j<4000;j++)
> 
> >   if ((  x2[j]=malloc(4000* sizeof(int *))) ==NULL)
> 
> 
> 
> Wrong type in the malloc call.  Using the often quoted idiom here would
> 
> have prevented this problem:
> 
> 
> 
>    x2[j] = malloc(4000 * sizeof *x2[j])
> 
> 
> 
> >     {i=-1; break; }
> 
> >
> 
> > if (i==-1) 
> 
> > { //error trapping here ....}
> 
> 
> 
> i may be -1 even without any error.

You are right check j for the value  that equals 4001 or not  is the
more elegant way.
> 
> 
> 
> > //x2[j][i] of 4000X4000 integers here can be used
> 
> >
> 
> > x=x2 ; // an alias of x2
> 
> >
> 
> > Can you get the difference?
> 
> 
> 
> Do you mean that they behave differently as operands of sizeof and of &?
> 
> 
> 
> -- 
> 
> Ben.


OK, I'll prevent the array allocated on the stack to be not destroyed 
first if I want to use int ** x outside the function that defines
int* x2[4000].

 

[toc] | [prev] | [next] | [standalone]

#24691

On 2012-08-21, 88888 Dihedral <dihedral88888@googlemail.com> wrote:
> On Wednesday, August 22, 2012 4:07:24 AM UTC+8, Ben Bacarisse wrote:
>> 88888 Dihedral <dihedral88888@googlemail.com> writes:
>> 
>> <snip>
>> > int **x ; // a pointer to a pointer of an integer
>> > int* x2[4000]; // an array of 4000 pointers to integers in the heap?
>> > int i,j; //i-n for ineger idexing
>> >
>> > // malloc might fail
>> >
>> > for(j=0;j<4000;j++)
>> >   if ((  x2[j]=malloc(4000* sizeof(int *))) ==NULL)
>> 
>> Wrong type in the malloc call.  Using the often quoted idiom here would
>> have prevented this problem:
>> 
>>    x2[j] = malloc(4000 * sizeof *x2[j])
>> 
>> >     {i=-1; break; }
>> >
>> > if (i==-1) 
>> > { //error trapping here ....}
>> 
>> i may be -1 even without any error.
>
> You are right check j for the value  that equals 4001 or not  is the
> more elegant way.

Not 4001, but 4000.

[toc] | [prev] | [next] | [standalone]

#24692

On Wednesday, August 22, 2012 6:09:36 AM UTC+8, Ike Naar wrote:
> On 2012-08-21, 88888 Dihedral <dihedral88888@googlemail.com> wrote:
> 
> > On Wednesday, August 22, 2012 4:07:24 AM UTC+8, Ben Bacarisse wrote:
> 
> >> 88888 Dihedral <dihedral88888@googlemail.com> writes:
> 
> >> 
> 
> >> <snip>
> 
> >> > int **x ; // a pointer to a pointer of an integer
> 
> >> > int* x2[4000]; // an array of 4000 pointers to integers in the heap?
> 
> >> > int i,j; //i-n for ineger idexing
> 
> >> >
> 
> >> > // malloc might fail
> 
> >> >
> 
> >> > for(j=0;j<4000;j++)
> 
> >> >   if ((  x2[j]=malloc(4000* sizeof(int *))) ==NULL)
> 
> >> 
> 
> >> Wrong type in the malloc call.  Using the often quoted idiom here would
> 
> >> have prevented this problem:
> 
> >> 
> 
> >>    x2[j] = malloc(4000 * sizeof *x2[j])
> 
> >> 
> 
> >> >     {i=-1; break; }
> 
> >> >
> 
> >> > if (i==-1) 
> 
> >> > { //error trapping here ....}
> 
> >> 
> 
> >> i may be -1 even without any error.
> 
> >
> 
> > You are right check j for the value  that equals 4001 or not  is the
> 
> > more elegant way.
> 
> 
> 
> Not 4001, but 4000.

Yeh, you are right! //for zero based indexing 

[toc] | [prev] | [next] | [standalone]

#24701

On Tuesday, August 21, 2012 3:13:20 PM UTC-7, 88888 Dihedral wrote:
> On Wednesday, August 22, 2012 6:09:36 AM UTC+8, Ike Naar wrote: > On 2012-08-21, 88888 Dihedral <dihedral88888@googlemail.com> wrote: > > > On Wednesday, August 22, 2012 4:07:24 AM UTC+8, Ben Bacarisse wrote: > > >> 88888 Dihedral <dihedral88888@googlemail.com> writes: > > >> > > >> <snip> > > >> > int **x ; // a pointer to a pointer of an integer > > >> > int* x2[4000]; // an array of 4000 pointers to integers in the heap? > > >> > int i,j; //i-n for ineger idexing > > >> > > > >> > // malloc might fail > > >> > > > >> > for(j=0;j<4000;j++) > > >> > if (( x2[j]=malloc(4000* sizeof(int *))) ==NULL) > > >> > > >> Wrong type in the malloc call. Using the often quoted idiom here would > > >> have prevented this problem: > > >> > > >> x2[j] = malloc(4000 * sizeof *x2[j]) > > >> > > >> > {i=-1; break; } > > >> > > > >> > if (i==-1) > > >> > { //error trapping here ....} > > >> > > >> i may be -1 even without any error. > > > > > > You are right check j for the value that equals 4001 or not is the > > > more elegant way. > > > > Not 4001, but 4000. Yeh, you are right! //for zero based indexing

The indexing base is irrelevant.
The relevant part is that as the loop is written, 
the loop continues only if i < 4000

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web