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 1 of 2  [1] 2  Next page →

#24635 — ridiculous warning or not?

Is this warning considered ridiculous?

I'll stop using that syntax if the compiler is
more correct than me.


% cat foo.c

char f[];

 

int main(void) { return (0); }

 

% cc foo.c

"foo.c", line 1: warning: null dimension: f


 

% cc -V

cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12

usage: cc [ options] files.  Use 'cc -flags' for details

[toc] | [next] | [standalone]

#24638

On 8/20/2012 5:41 AM, kerravon wrote:
> Is this warning considered ridiculous?

     Not by me.

> I'll stop using that syntax if the compiler is
> more correct than me.
>
> % cat foo.c
>
> char f[];

      This line attempts to define an array.  What is an array?
A collection of a fixed number of elements, all of the same type.
What kind of elements does this array contain?  `char', it seems:
That's fine.  How many?  Um, er, ah, well, ...

     Perhaps you intended `extern char f[];', which would be a
different matter entirely: Not an attempt to define an array,
but a declaration that an array is defined somewhere else --
and that the size will be found at that "somewhere else."

> int main(void) { return (0); }
>
>
>
> % cc foo.c
>
> "foo.c", line 1: warning: null dimension: f

   Another compiler says

	foo.c:1: warning: array 'f' assumed to have one element

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#24651

On Mon, 20 Aug 2012 02:41:21 -0700, kerravon wrote:

> char f[];

How big do you want that to be?



-- 
[  T  H  I  S     S  P  A  C  E     I  S     F  O  R     R  E  N  T  ]
Troppo poca cultura ci rende ignoranti, troppa ci rende folli.
  -- fathermckenzie di it.cultura.linguistica.italiano
<http://xkcd.com/397/>

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

#24654

On 8/20/2012 5:41 AM, kerravon wrote:
> Is this warning considered ridiculous?
>
> I'll stop using that syntax if the compiler is
> more correct than me.

It depends on what your goal is.

> % cat foo.c
>
> char f[];

Did you mean "extern char f[];"?  As in, "there is an array of chars defined 
elsewhere, given the name 'f', and of unknown size"?

If you didn't mean "extern", then what, exactly, is that statement supposed 
to mean?

>
> int main(void) { return (0); }
>
>
>
> % cc foo.c
>
> "foo.c", line 1: warning: null dimension: f

Sounds reasonable to me.  Without the "extern", the statement is unusual to 
say the least.  The warning tells you that you probably meant to give f a size.

Just like many compilers will give a warning on lines such as:

     if ( foo = 0 )

because you probably meant "==", this warning is along the same "are you 
sure you meant to do that" line.

Of course, as has been pointed out many times in this group, compilers are 
free to give warnings on literally anything.

-- 
Kenneth Brody

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

#26052

Kenneth Brody <kenbrody@spamcop.net> writes:

> On 8/20/2012 5:41 AM, kerravon wrote:
>> Is this warning considered ridiculous?
>>
>> I'll stop using that syntax if the compiler is
>> more correct than me.
>
> It depends on what your goal is.
>
>> % cat foo.c
>>
>> char f[];
>
> Did you mean "extern char f[];"?  As in, "there is an array of chars
> defined elsewhere, given the name 'f', and of unknown size"?
>
> If you didn't mean "extern", then what, exactly, is that statement
> supposed to mean?

Perhaps it's supposed to mean just what the C Standard
says it means:  that 'f' is a character array;  that
the character array 'f' is defined in this translation
unit;  that the array could be given a specific size
in a later declaration, or later definition;  and that,
if not given a specific size explicitly (perhaps as a
consequence of a subsequent definition including an
initializer), it will be defined implicitly as having
one element, initialized using the value zero.

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

#24666

On 20/08/2012 10:41, kerravon wrote:
> Is this warning considered ridiculous?

No

> 
> I'll stop using that syntax if the compiler is
> more correct than me.
> 
> 
> % cat foo.c
> 
> char f[];

I hope you are not using 'char f[];' where you mean to use 'char * f;',
as they are very different things.

~Andrew

> 
>  
> 
> int main(void) { return (0); }
> 
>  
> 
> % cc foo.c
> 
> "foo.c", line 1: warning: null dimension: f
> 
> 
>  
> 
> % cc -V
> 
> cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12
> 
> usage: cc [ options] files.  Use 'cc -flags' for details
> 

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

#24668

kerravon <kerravon@w3.to> writes:

> Is this warning considered ridiculous?
>
> I'll stop using that syntax if the compiler is
> more correct than me.
>
>
> % cat foo.c
>
> char f[];
>
> int main(void) { return (0); }
>
> % cc foo.c
>
> "foo.c", line 1: warning: null dimension: f

The warning is true, but possibly misleading.  What you've written could
certainly be called a "null dimension" but the effect should be as if
you had written

  char f[1];

The C standard gives meaning to this bizarre syntax for what I can only
imagine are historical reasons.  There's no sensible reason to write
such code.

This makes it probable that others, who have suggested you did not mean
what you wrote, are right.  One way or the other, you should stop using
this syntax because it either does not mean what you want, or (vanishing
unlikely) it's a confusing way to write what you do want (why would you
want am external one-element array?).

-- 
Ben.

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

#24674

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> kerravon <kerravon@w3.to> writes:
[...]
>> char f[];
[...]
>> "foo.c", line 1: warning: null dimension: f
>
> The warning is true, but possibly misleading.  What you've written could
> certainly be called a "null dimension" but the effect should be as if
> you had written
>
>   char f[1];
>
> The C standard gives meaning to this bizarre syntax for what I can only
> imagine are historical reasons.  There's no sensible reason to write
> such code.
>
> This makes it probable that others, who have suggested you did not mean
> what you wrote, are right.  One way or the other, you should stop using
> this syntax because it either does not mean what you want, or (vanishing
> unlikely) it's a confusing way to write what you do want (why would you
> want am external one-element array?).

As far as I can tell, the rule that `char f[];` is treated as `char
f[1];` isn't even stated explicitly.

N1570 6.9.2p2, External definitions, says:

    A declaration of an identifier for an object that has file scope
    without an initializer, and without a storage-class specifier or
    with the storage-class specifier static, constitutes a *tentative
    definition*. If a translation unit contains one or more tentative
    definitions for an identifier, and the translation unit contains
    no external definition for that identifier, then the behavior
    is exactly as if the translation unit contains a file scope
    declaration of that identifier, with the composite type as of
    the end of the translation unit, with an initializer equal to 0.

An example (non-normative) says:

    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;

So this:

    char f[];

is treated as:

    char f[] = 0;

which causes `f` to inherit its size from the initializer.

Except that

    char f[] = 0;

is invalid.  6.7.9p16 says:

    Otherwise, the initializer for an object that has aggregate or union
    type shall be a brace-enclosed list of initializers for the elements
    or named members.

A twist: That "shall" is not in a constraint, so it's undefined
behavior, not something that requires a diagnostic.

Apparently we have to interpret the "initializer equal to 0" to mean
`{ 0 }` rather than `0` in this case.  And we're supposed to infer
from that that `f` has exactly one element; apparently `{ 0 }` is
"equal to 0" but `{ 0, 0 }` isn't.

-- 
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]

#26054

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> kerravon <kerravon@w3.to> writes:
> [...]
>>> char f[];
> [...]
>>> "foo.c", line 1: warning: null dimension: f
>>
>> The warning is true, but possibly misleading.  What you've written could
>> certainly be called a "null dimension" but the effect should be as if
>> you had written
>>
>>   char f[1];
>>
>> The C standard gives meaning to this bizarre syntax for what I can only
>> imagine are historical reasons.  There's no sensible reason to write
>> such code.
>>
>> This makes it probable that others, who have suggested you did not mean
>> what you wrote, are right.  One way or the other, you should stop using
>> this syntax because it either does not mean what you want, or (vanishing
>> unlikely) it's a confusing way to write what you do want (why would you
>> want am external one-element array?).
>
> As far as I can tell, the rule that `char f[];` is treated as `char
> f[1];` isn't even stated explicitly.
>
> N1570 6.9.2p2, External definitions, says:
>
>     A declaration of an identifier for an object that has file scope
>     without an initializer, and without a storage-class specifier or
>     with the storage-class specifier static, constitutes a *tentative
>     definition*. If a translation unit contains one or more tentative
>     definitions for an identifier, and the translation unit contains
>     no external definition for that identifier, then the behavior
>     is exactly as if the translation unit contains a file scope
>     declaration of that identifier, with the composite type as of
>     the end of the translation unit, with an initializer equal to 0.
>
> An example (non-normative) says:
>
>     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;
>
> So this:
>
>     char f[];
>
> is treated as:
>
>     char f[] = 0;

No, it would be  'char f[] = {0};'  as the implementation is
obliged to do by 6.7.9p16 -- implementations are obliged to
follow "shall" directives.

> which causes `f` to inherit its size from the initializer.
>
> Except that
>
>     char f[] = 0;
>
> is invalid.  6.7.9p16 says:
>
>     Otherwise, the initializer for an object that has aggregate or union
>     type shall be a brace-enclosed list of initializers for the elements
>     or named members.
>
> A twist: That "shall" is not in a constraint, so it's undefined
> behavior, not something that requires a diagnostic.
>
> Apparently we have to interpret the "initializer equal to 0" to mean
> `{ 0 }` rather than `0` in this case.  And we're supposed to infer
> from that that `f` has exactly one element; apparently `{ 0 }` is
> "equal to 0" but `{ 0, 0 }` isn't.

{ 0, 0 } is two initializers, not one.

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

#26091

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> As far as I can tell, the rule that `char f[];` is treated as `char
>> f[1];` isn't even stated explicitly.
>>
>> N1570 6.9.2p2, External definitions, says:
>>
>>     A declaration of an identifier for an object that has file scope
>>     without an initializer, and without a storage-class specifier or
>>     with the storage-class specifier static, constitutes a *tentative
>>     definition*. If a translation unit contains one or more tentative
>>     definitions for an identifier, and the translation unit contains
>>     no external definition for that identifier, then the behavior
>>     is exactly as if the translation unit contains a file scope
>>     declaration of that identifier, with the composite type as of
>>     the end of the translation unit, with an initializer equal to 0.
>>
>> An example (non-normative) says:
>>
>>     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;
>>
>> So this:
>>
>>     char f[];
>>
>> is treated as:
>>
>>     char f[] = 0;
>
> No, it would be  'char f[] = {0};'  as the implementation is
> obliged to do by 6.7.9p16 -- implementations are obliged to
> follow "shall" directives.

Implementations are obliged to follow *all* normative requirements
in the standard.  6.9.2p2 requires an implicit "initializer equal
to 0".  I wouldn't say that `{0}` is "equal to 0".

>> which causes `f` to inherit its size from the initializer.
>>
>> Except that
>>
>>     char f[] = 0;
>>
>> is invalid.  6.7.9p16 says:
>>
>>     Otherwise, the initializer for an object that has aggregate or union
>>     type shall be a brace-enclosed list of initializers for the elements
>>     or named members.
>>
>> A twist: That "shall" is not in a constraint, so it's undefined
>> behavior, not something that requires a diagnostic.
>>
>> Apparently we have to interpret the "initializer equal to 0" to mean
>> `{ 0 }` rather than `0` in this case.  And we're supposed to infer
>> from that that `f` has exactly one element; apparently `{ 0 }` is
>> "equal to 0" but `{ 0, 0 }` isn't.
>
> { 0, 0 } is two initializers, not one.

{ 0, 0 } is one initializer, which contains two more initializers.

N1370 6.7.9p1:

    initializer:
        assignment-expression
        { initializer-list }
        { initializer-list , }

The idea that `char f[];` is implicitly `char f[1];` is sufficiently
non-obvious (and IMHO counterintuitive) that it should be stated
explicitly.  We shouldn't have to depend on a flimsy and IMHO incorrect
chain of reasoning that appears only in a non-normative example.

-- 
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]

#26116

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
> [...snip-a-lot...]
>>> So this:
>>>
>>>     char f[];
>>>
>>> is treated as:
>>>
>>>     char f[] = 0;
>>
>> No, it would be  'char f[] = {0};'  as the implementation is
>> obliged to do by 6.7.9p16 -- implementations are obliged to
>> follow "shall" directives.
>
> Implementations are obliged to follow *all* normative requirements
> in the standard.  6.9.2p2 requires an implicit "initializer equal
> to 0".  I wouldn't say that `{0}` is "equal to 0".
>
>[...snip-some-more...]
>
>>> Apparently we have to interpret the "initializer equal to 0" to mean
>>> `{ 0 }` rather than `0` in this case.  And we're supposed to infer
>>> from that that `f` has exactly one element; apparently `{ 0 }` is
>>> "equal to 0" but `{ 0, 0 }` isn't.
>>
>> { 0, 0 } is two initializers, not one.
>
> { 0, 0 } is one initializer, which contains two more initializers.
> [...snip elaboration...]

My comments were kind of half frivolous, because I find
it hard to believe someone would take this question so
seriously, when it seems perfectly obvious what is
intended.  I do think my comments have some degree of
merit (and yours also), but not sufficient to overcome
the level of silliness present (for which I am more
to blame than you).

Therefore, rather than continuing on the particular
points above, I would like to quote from Defect Report #11
(slightly reformatted):

    Question 3  Initialization of tentative definitions
    --------------------------------------------------- 
    If the file scope declaration

        int i[10];

    appears in a translation unit, subclause 6.7.2 suggests
    that it is implicitly initialized as if

        int i[10] = 0;

    appears at the end of the translation unit.  However, this
    initializer is invalid, since subclause 6.5.7 prescribes
    that the initializer for any object of array type must be
    brace-enclosed.  We believe that the intention of subclause
    6.7.2 is that this declaration has an implicit initializer
    of

        int i[10] = {0};

    Is this true?

    Response
    --------
    Subclause 6.7.2 External object definitions contains the
    following excerpt:

        If a translation unit contains one or more tentative
        definitions for an identifier, and the translation unit
        contains no external definition for that identifier,
        then the behavior is exactly as if the translation unit
        contains a file scope declaration of that identifier,
        with the composite type as of the end of the
        translation unit, with an initializer equal to 0.

    This statement describes an effect and not a literal token
    sequence.  Therefore, this example does not contain an
    error.

Please note the first sentence in the last paragraph.

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

#26125

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:
>> [...snip-a-lot...]
>>>> So this:
>>>>
>>>>     char f[];
>>>>
>>>> is treated as:
>>>>
>>>>     char f[] = 0;
>>>
>>> No, it would be  'char f[] = {0};'  as the implementation is
>>> obliged to do by 6.7.9p16 -- implementations are obliged to
>>> follow "shall" directives.
>>
>> Implementations are obliged to follow *all* normative requirements
>> in the standard.  6.9.2p2 requires an implicit "initializer equal
>> to 0".  I wouldn't say that `{0}` is "equal to 0".
>>
>>[...snip-some-more...]
>>
>>>> Apparently we have to interpret the "initializer equal to 0" to mean
>>>> `{ 0 }` rather than `0` in this case.  And we're supposed to infer
>>>> from that that `f` has exactly one element; apparently `{ 0 }` is
>>>> "equal to 0" but `{ 0, 0 }` isn't.
>>>
>>> { 0, 0 } is two initializers, not one.
>>
>> { 0, 0 } is one initializer, which contains two more initializers.
>> [...snip elaboration...]
>
> My comments were kind of half frivolous, because I find
> it hard to believe someone would take this question so
> seriously, when it seems perfectly obvious what is
> intended.  I do think my comments have some degree of
> merit (and yours also), but not sufficient to overcome
> the level of silliness present (for which I am more
> to blame than you).
>
> Therefore, rather than continuing on the particular
> points above, I would like to quote from Defect Report #11
> (slightly reformatted):
>
[snip]
>     Response
>     --------
>     Subclause 6.7.2 External object definitions contains the
>     following excerpt:
>
>         If a translation unit contains one or more tentative
>         definitions for an identifier, and the translation unit
>         contains no external definition for that identifier,
>         then the behavior is exactly as if the translation unit
>         contains a file scope declaration of that identifier,
>         with the composite type as of the end of the
>         translation unit, with an initializer equal to 0.
>
>     This statement describes an effect and not a literal token
>     sequence.  Therefore, this example does not contain an
>     error.
>
> Please note the first sentence in the last paragraph.

Interesting.  That's
    http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_011.html
submitted 1992-12-10 against C90; it resulted in the addition of
the footnote in question.

Personally, I'm not satisfied with the statement that it "describes
an effect and not a literal token sequence", or with the conclusion
that an initializer "equal to 0" implies that the array has 1
element.  The standard isn't a mathematically formal document, but
this is one of those cases where I think it needs to be more precise.
The phrase "equal to 0" has an exact meaning; I dislike the standard
using it so loosely.

-- 
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]

#26138

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:
>>> [...snip-a-lot...]
>>>>> So this:
>>>>>
>>>>>     char f[];
>>>>>
>>>>> is treated as:
>>>>>
>>>>>     char f[] = 0;
>>>>
>>>> No, it would be  'char f[] = {0};'  as the implementation is
>>>> obliged to do by 6.7.9p16 -- implementations are obliged to
>>>> follow "shall" directives.
>>>
>>> Implementations are obliged to follow *all* normative requirements
>>> in the standard.  6.9.2p2 requires an implicit "initializer equal
>>> to 0".  I wouldn't say that `{0}` is "equal to 0".
>>>
>>>[...snip-some-more...]
>>>
>>>>> Apparently we have to interpret the "initializer equal to 0" to mean
>>>>> `{ 0 }` rather than `0` in this case.  And we're supposed to infer
>>>>> from that that `f` has exactly one element; apparently `{ 0 }` is
>>>>> "equal to 0" but `{ 0, 0 }` isn't.
>>>>
>>>> { 0, 0 } is two initializers, not one.
>>>
>>> { 0, 0 } is one initializer, which contains two more initializers.
>>> [...snip elaboration...]
>>
>> My comments were kind of half frivolous, because I find
>> it hard to believe someone would take this question so
>> seriously, when it seems perfectly obvious what is
>> intended.  I do think my comments have some degree of
>> merit (and yours also), but not sufficient to overcome
>> the level of silliness present (for which I am more
>> to blame than you).
>>
>> Therefore, rather than continuing on the particular
>> points above, I would like to quote from Defect Report #11
>> (slightly reformatted):
>>
> [snip]
>>     Response
>>     --------
>>     Subclause 6.7.2 External object definitions contains the
>>     following excerpt:
>>
>>         If a translation unit contains one or more tentative
>>         definitions for an identifier, and the translation unit
>>         contains no external definition for that identifier,
>>         then the behavior is exactly as if the translation unit
>>         contains a file scope declaration of that identifier,
>>         with the composite type as of the end of the
>>         translation unit, with an initializer equal to 0.
>>
>>     This statement describes an effect and not a literal token
>>     sequence.  Therefore, this example does not contain an
>>     error.
>>
>> Please note the first sentence in the last paragraph.
>
> Interesting.  That's
>     http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_011.html
> submitted 1992-12-10 against C90; it resulted in the addition of
> the footnote in question.
>
> Personally, I'm not satisfied with the statement that it "describes
> an effect and not a literal token sequence", or with the conclusion
> that an initializer "equal to 0" implies that the array has 1
> element.  The standard isn't a mathematically formal document, but
> this is one of those cases where I think it needs to be more precise.
> The phrase "equal to 0" has an exact meaning; I dislike the standard
> using it so loosely.

I will try to follow up soon in the comp.std.c thread.

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

#26053

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

> kerravon <kerravon@w3.to> writes:
>
>> % cat foo.c
>>
>> char f[];
>>
>> int main(void) { return (0); }
>>
> [snip] the effect should be as if you had written
>
>   char f[1];
>
> The C standard gives meaning to this bizarre syntax for what I can only
> imagine are historical reasons.  There's no sensible reason to write
> such code. [snip]

Here's one possible use case

    typedef int (*Converter)( int );
    Converter foos[];

    int foo1( int x ){ ... }
    int foo2( int x ){ ... }
    int foo3( int x ){ ... }
    ...

    Convertor foos[] = { foo1, foo2, foo3, ... etc ... };

Personally I think there is value in giving a declaration that
also stipulates the item being declared will be defined in
this source file.  Obviously this example could be done
instead using 'extern' but for cases like this one I normally
would prefer omitting the 'extern' in the source file that
defines 'foos'.

The default semantics of there nominally being one element
is, I would guess, simply a consequence of the default
initialization rules.

Incidentally, a similar pattern is legal with struct's (or union's):

    struct NotYetComplete something;

    ... functions ...

    struct NotYetComplete {
        ... define struct contents here ...
    };

    ... functions that can access the internals of 'something' ...

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

#26100

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> kerravon <kerravon@w3.to> writes:
>>
>>> % cat foo.c
>>>
>>> char f[];
>>>
>>> int main(void) { return (0); }
>>>
>> [snip] the effect should be as if you had written
>>
>>   char f[1];
>>
>> The C standard gives meaning to this bizarre syntax for what I can only
>> imagine are historical reasons.  There's no sensible reason to write
>> such code. [snip]
>
> Here's one possible use case
>
>     typedef int (*Converter)( int );
>     Converter foos[];
>
>     int foo1( int x ){ ... }
>     int foo2( int x ){ ... }
>     int foo3( int x ){ ... }
>     ...
>
>     Convertor foos[] = { foo1, foo2, foo3, ... etc ... };
>
> Personally I think there is value in giving a declaration that
> also stipulates the item being declared will be defined in
> this source file.  Obviously this example could be done
> instead using 'extern' but for cases like this one I normally
> would prefer omitting the 'extern' in the source file that
> defines 'foos'.

A misunderstanding -- I use that style all the time.  The thing I could
see no sensible reason for writing was what OP wrote: a tentative
definition and nothing else.

> 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.

> Incidentally, a similar pattern is legal with struct's (or union's):
>
>     struct NotYetComplete something;
>
>     ... functions ...
>
>     struct NotYetComplete {
>         ... define struct contents here ...
>     };
>
>     ... functions that can access the internals of 'something' ...

The same misunderstanding.  Explicitly completing something later is
very natural.  Having it be completed automatically is, to me, a little
odd.

-- 
Ben.

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

#26114

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.

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

#26118

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> 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.

I don't believe the normative wording actually says that, because of
a quibble about the phrase "equal to 0".  I've posted to comp.std.c,
subject "Tentative array object definition".

-- 
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]

#26136

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>> 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.
>
> I don't believe the normative wording actually says that, because of
> a quibble about the phrase "equal to 0".  I've posted to comp.std.c,
> subject "Tentative array object definition".

That's good.  I may have a chance to follow up there.

When writing in comp.lang.c, I try to read the Standard how
the committee reads it or expects it will be read.  To me
that seems like the best fit with what comp.lang.c is for.

I know there are other ways of reading the Standard, but it
seems better to confine those to comp.std.c.  That also largely
includes the meta-discussion of what the preferred reading
mode, or modes, ought to be.

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?

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

#26148

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).

(And "i" is a lousy name for an array!)

-- 
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]

#29438

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?

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web