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

Groups > comp.std.c > #1548 > unrolled thread

When is the complete type of an external definition known?

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

Contents

  When is the complete type of an external definition known? Vlad from Moscow <vlad.moscow@mail.ru> - 2012-08-19 13:40 -0700
    Re: When is the complete type of an external definition known? Keith Thompson <kst-u@mib.org> - 2012-08-19 14:06 -0700
      Re: When is the complete type of an external definition known? Vlad from Moscow <vlad.moscow@mail.ru> - 2012-08-19 14:30 -0700
        Re: When is the complete type of an external definition known? Ike Naar <ike@iceland.freeshell.org> - 2012-08-19 21:56 +0000
          Re: When is the complete type of an external definition known? Vlad from Moscow <vlad.moscow@mail.ru> - 2012-08-19 16:42 -0700
            Re: When is the complete type of an external definition known? Keith Thompson <kst-u@mib.org> - 2012-08-19 19:22 -0700
              Re: When is the complete type of an external definition known? Wojtek Lerch <wojtek_l@yahoo.ca> - 2012-08-20 10:57 -0400
                Re: When is the complete type of an external definition known? Keith Thompson <kst-u@mib.org> - 2012-08-20 13:01 -0700
                  Re: When is the complete type of an external definition known? Wojtek Lerch <wojtek_l@yahoo.ca> - 2012-08-20 16:58 -0400
                Re: When is the complete type of an external definition known? pacman@kosh.dhis.org (Alan Curry) - 2012-08-21 00:44 +0000
            Re: When is the complete type of an external definition known? Ike Naar <ike@sverige.freeshell.org> - 2012-08-20 05:57 +0000
              Re: When is the complete type of an external definition known? Vlad from Moscow <vlad.moscow@mail.ru> - 2012-08-20 03:22 -0700
                Re: When is the complete type of an external definition known? Ike Naar <ike@sverige.freeshell.org> - 2012-08-20 12:27 +0000
                  Re: When is the complete type of an external definition known? Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-20 17:04 +0200
                    Re: When is the complete type of an external definition known? Ike Naar <ike@iceland.freeshell.org> - 2012-08-20 16:35 +0000
                      Re: When is the complete type of an external definition known? Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-20 20:43 +0200
            Re: When is the complete type of an external definition known? James Kuyper <jameskuyper@verizon.net> - 2012-08-20 08:46 -0400
    Re: When is the complete type of an external definition known? Vlad from Moscow <vlad.moscow@mail.ru> - 2012-08-19 14:24 -0700
    Re: When is the complete type of an external definition known? "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2012-08-19 23:36 +0200
      Re: When is the complete type of an external definition known? Vlad from Moscow <vlad.moscow@mail.ru> - 2012-08-19 14:46 -0700

#1548 — When is the complete type of an external definition known?

Let consider a sample code

#include <stdio.h>

static int a[];

int main( void )
{
   printf( "sizeof( a ) = %ul\n", sizeof( a ) );

   return 0;
}

extern int a[10];

Shall a compiler issue an error for this sample code? Or the composite type of the array 'a' shall be known already in the point where the printf is used?

[toc] | [next] | [standalone]

#1550

Vlad from Moscow <vlad.moscow@mail.ru> writes:
> Let consider a sample code
>
>     #include <stdio.h>    
>    
>     static int a[];
>    
>     int main( void )
>     {
>        printf( "sizeof( a ) = %ul\n", sizeof( a ) );
>    
>        return 0;
>     }
>    
>     extern int a[10];
>
> Shall a compiler issue an error for this sample code? Or the composite
> type of the array 'a' shall be known already in the point where the
> printf is used?

(You want "%zu", not "%ul", for a size_t argument.)

It's a constraint violation, requiring a diagnostic.

N1570 6.7.6.2p4:

    If the size is not present, the array type is an incomplete type.

N1570 6.5.3.4p1:

    Constraints

    The sizeof operator shall not be applied to an expression that has
    function type or an incomplete type,
    [...]

`a` has an incomplete type at the point where `sizeof` is applied to it.
(Its type becomes complete after the `extern int a[10];` declaration.)

BTW, unless you think there's an error or ambiguity in the wording of
the C standard, this question would probably be more appropriate in
comp.lang.c.  comp.std.c discusses the language standard document;
comp.lang.c discusses the language defined by that standard.

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

#1552

понедельник, 20 августа 2012 г., 1:06:42 UTC+4 пользователь Keith Thompson написал:
> Vlad from Moscow <vlad.moscow@mail.ru> writes:
> 
> > Let consider a sample code
> 
> >
> 
> >     #include <stdio.h>    
> 
> >    
> 
> >     static int a[];
> 
> >    
> 
> >     int main( void )
> 
> >     {
> 
> >        printf( "sizeof( a ) = %ul\n", sizeof( a ) );
> 
> >    
> 
> >        return 0;
> 
> >     }
> 
> >    
> 
> >     extern int a[10];
> 
> >
> 
> > Shall a compiler issue an error for this sample code? Or the composite
> 
> > type of the array 'a' shall be known already in the point where the
> 
> > printf is used?
> 
> 
> 
> (You want "%zu", not "%ul", for a size_t argument.)
> 
> 
> 
> It's a constraint violation, requiring a diagnostic.
> 
> 
> 
> N1570 6.7.6.2p4:
> 
> 
> 
>     If the size is not present, the array type is an incomplete type.
> 
> 
> 
> N1570 6.5.3.4p1:
> 
> 
> 
>     Constraints
> 
> 
> 
>     The sizeof operator shall not be applied to an expression that has
> 
>     function type or an incomplete type,
> 
>     [...]
> 
> 
> 
> `a` has an incomplete type at the point where `sizeof` is applied to it.
> 
> (Its type becomes complete after the `extern int a[10];` declaration.)
> 
> 
> 
> BTW, unless you think there's an error or ambiguity in the wording of
> 
> the C standard, this question would probably be more appropriate in
> 
> comp.lang.c.  comp.std.c discusses the language standard document;
> 
> comp.lang.c discusses the language defined by that standard.
> 
> 
> 
> -- 
> 
> 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"

According to paragraph 2 of section 6.9.2 External object definitions

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

So it is not clear shall a compiler issue an error or not, because as it is written in the quote "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"

So what does mean this "behavior" and where is this file scope declaration with the composite type in the translation unit?

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

#1555

On 2012-08-19, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
>> Vlad from Moscow <vlad.moscow@mail.ru> writes:
>> 
>> > Let consider a sample code
>> >
>> >     #include <stdio.h>    
>> >     static int a[];
>> >     int main( void )
>> >     {
>> >        printf( "sizeof( a ) = %ul\n", sizeof( a ) );
>> >        return 0;
>> >     }
>> >     extern int a[10];
>> 
>> > Shall a compiler issue an error for this sample code? Or the composite
>> > type of the array 'a' shall be known already in the point where the
>> > printf is used?
>
> According to paragraph 2 of section 6.9.2 External object definitions
> "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."

  static int a[];

violates 6.9.2 p3:
"If the declaration of an identifier for an object is a tentative
definition and has internal linkage, the declared type shall not be
an incomplete type."

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

#1556

понедельник, 20 августа 2012 г., 1:56:49 UTC+4 пользователь Ike Naar написал:
> On 2012-08-19, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
> 
> >> Vlad from Moscow <> writes:
> 
> >> 
> 
> >> > Let consider a sample code
> 
> >> >
> 
> >> >     #include <stdio.h>    
> 
> >> >     static int a[];
> 
> >> >     int main( void )
> 
> >> >     {
> 
> >> >        printf( "sizeof( a ) = %ul\n", sizeof( a ) );
> 
> >> >        return 0;
> 
> >> >     }
> 
> >> >     extern int a[10];
> 
> >> 
> 
> >> > Shall a compiler issue an error for this sample code? Or the composite
> 
> >> > type of the array 'a' shall be known already in the point where the
> 
> >> > printf is used?
> 
> >
> 
> > According to paragraph 2 of section 6.9.2 External object definitions
> 
> > "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."
> 
> 
> 
>   static int a[];
> 
> 
> 
> violates 6.9.2 p3:
> 
> "If the declaration of an identifier for an object is a tentative
> 
> definition and has internal linkage, the declared type shall not be
> 
> an incomplete type."

I understand paragraph #2 of section 6.9.2 External object definitions that says that "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." 
that in my sample the array has complete composite type int [10].

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

#1557

Vlad from Moscow <vlad.moscow@mail.ru> writes:
> понедельник, 20 августа 2012 г., 1:56:49 UTC+4 пользователь Ike Naar написал:
>> On 2012-08-19, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
[...]
>>   static int a[];
>> 
>> violates 6.9.2 p3:
>> 
>> "If the declaration of an identifier for an object is a tentative
>> definition and has internal linkage, the declared type shall not be
>> an incomplete type."
>
> I understand paragraph #2 of section 6.9.2 External object definitions
> that says that "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."  that in my sample the array
> has complete composite type int [10].

It's paragraph 3 (which Ike Naar quoted) that applies here.  Your
declaration

    static int a[];

is illegal (more precisely a constraint violation).

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

#1566

On 19-Aug-12 10:22 PM, Keith Thompson wrote:
> Vlad from Moscow <vlad.moscow@mail.ru> writes:
>> понедельник, 20 августа 2012 г., 1:56:49 UTC+4 пользователь Ike Naar написал:
>>> On 2012-08-19, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
> [...]
>>>    static int a[];
>>>
>>> violates 6.9.2 p3:
>>>
>>> "If the declaration of an identifier for an object is a tentative
>>> definition and has internal linkage, the declared type shall not be
>>> an incomplete type."
>
> ... (more precisely a constraint violation).

Actually that paragraph is in a Semantics section, not in a Constraints 
section.  It's plain undefined behaviour without a promise of a diagnostic.

Out of curiosity, does anybody know the reason for this restriction?  It 
sounds like a useful thing to be able to do.  (And I have to admit that 
did it more than once, before I knew about this.)  Is it because 
different compilers used to interpret it differently back in the day, 
and the standard didn't want to break them?  The Rationale doesn't seem 
to mention "tentative" at all.

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

#1570

Wojtek Lerch <wojtek_l@yahoo.ca> writes:
> On 19-Aug-12 10:22 PM, Keith Thompson wrote:
>> Vlad from Moscow <vlad.moscow@mail.ru> writes:
>>> понедельник, 20 августа 2012 г., 1:56:49 UTC+4 пользователь Ike Naar написал:
>>>> On 2012-08-19, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
>> [...]
>>>>    static int a[];
>>>>
>>>> violates 6.9.2 p3:
>>>>
>>>> "If the declaration of an identifier for an object is a tentative
>>>> definition and has internal linkage, the declared type shall not be
>>>> an incomplete type."
>>
>> ... (more precisely a constraint violation).
>
> Actually that paragraph is in a Semantics section, not in a Constraints 
> section.  It's plain undefined behaviour without a promise of a diagnostic.
>
> Out of curiosity, does anybody know the reason for this restriction?  It 
> sounds like a useful thing to be able to do.  (And I have to admit that 
> did it more than once, before I knew about this.)  Is it because 
> different compilers used to interpret it differently back in the day, 
> and the standard didn't want to break them?  The Rationale doesn't seem 
> to mention "tentative" at all.

And assuming the restriction is necessary, why isn't it a constraint?
Is it difficult for a compiler to detect a violation?

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

#1572

On 20-Aug-12 4:01 PM, Keith Thompson wrote:
> Wojtek Lerch <wojtek_l@yahoo.ca> writes:
>>> [...]
>>>>>     static int a[];
>>>>>
>>>>> violates 6.9.2 p3:
...
>> Out of curiosity, does anybody know the reason for this restriction?  It
>> sounds like a useful thing to be able to do.  (And I have to admit that
>> did it more than once, before I knew about this.)  Is it because
>> different compilers used to interpret it differently back in the day,
>> and the standard didn't want to break them?  The Rationale doesn't seem
>> to mention "tentative" at all.
>
> And assuming the restriction is necessary, why isn't it a constraint?

If the reason is because at the time all compilers treated this 
construct as valid but interpreted it with different semantics, then 
making it a constraint would mean that some compilers would need to 
change (and start to produce a diagnostic).

Compare this to 6.9p5, which makes it undefined behaviour to have 
multiple definitions of the same symbol with external linkage, or a 
missing definition of a symbol that is referenced.  I don't think I have 
ever worked with a linker that wouldn't treat those as fatal errors, but 
I assume that the reason this is not a constraint either is because back 
in the eighties some linkers accepted it.

> Is it difficult for a compiler to detect a violation?

As far as I can tell, recognizing that the type is incomplete is the 
only non-trivial part.

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

#1574

In article <a9f1hmFe4bU1@mid.individual.net>,
Wojtek Lerch  <wojtek_l@yahoo.ca> wrote:
>On 19-Aug-12 10:22 PM, Keith Thompson wrote:
>> Vlad from Moscow <vlad.moscow@mail.ru> writes:
>>> понедельник, 20 августа 2012 г., 1:56:49 UTC+4
>пользователь Ike Naar написал:
>>>> On 2012-08-19, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
>> [...]
>>>>    static int a[];
>>>>
>>>> violates 6.9.2 p3:
>>>>
>>>> "If the declaration of an identifier for an object is a tentative
>>>> definition and has internal linkage, the declared type shall not be
>>>> an incomplete type."
>>
>> ... (more precisely a constraint violation).
>
>Actually that paragraph is in a Semantics section, not in a Constraints 
>section.  It's plain undefined behaviour without a promise of a diagnostic.
>
>Out of curiosity, does anybody know the reason for this restriction?  It 
>sounds like a useful thing to be able to do.  (And I have to admit that 
>did it more than once, before I knew about this.)  Is it because 
>different compilers used to interpret it differently back in the day, 
>and the standard didn't want to break them?  The Rationale doesn't seem 
>to mention "tentative" at all.

When I asked this question before, the most believable answer was that
ancient compilers didn't handle this case because it would have required a
second compiler pass. Without the static keyword, the linker could finish up
whatever the compiler couldn't do in its single pass. With static, the linker
didn't get enough information.

Assuming the last of the single-pass compilers has finally died out, it
should be possible to get this fixed. It needs someone who cares enough to
make it an official proposal.

-- 
Alan Curry

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

#1558

On 2012-08-19, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
> ???????????, 20 ??????? 2012??., 1:56:49 UTC+4 ???????????? Ike Naar ???????:
>> 
>>   static int a[];
>> 
>> violates 6.9.2 p3:
>> "If the declaration of an identifier for an object is a tentative
>> definition and has internal linkage, the declared type shall not be
>> an incomplete type."
>
> I understand paragraph #2 of section 6.9.2 External object definitions that says that "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." 
> that in my sample the array has complete composite type int [10].

I think that "the declared type" in p3 refers to the type used
in the declaration, not to the composite type.

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

#1563

понедельник, 20 августа 2012 г., 9:57:51 UTC+4 пользователь Ike Naar написал:
> On 2012-08-19, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
> 
> > ???????????, 20 ??????? 2012??., 1:56:49 UTC+4 ???????????? Ike Naar ???????:
> 
> >> 
> 
> >>   static int a[];
> 
> >> 
> 
> >> violates 6.9.2 p3:
> 
> >> "If the declaration of an identifier for an object is a tentative
> 
> >> definition and has internal linkage, the declared type shall not be
> 
> >> an incomplete type."
> 
> >
> 
> > I understand paragraph #2 of section 6.9.2 External object definitions that says that "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." 
> 
> > that in my sample the array has complete composite type int [10].
> 
> 
> 
> I think that "the declared type" in p3 refers to the type used
> 
> in the declaration, not to the composite type.

I do not like answers that starts with "I think' (without any offence). You think such a way others think aother way. Do we deal with a standard or not?
Well, let change the original example the following way

#include <stdio.h>

int a[];

int main( void )
{
   printf( "sizeof( a ) = %ul\n", sizeof( a ) );  

   return ( 0 );
}

int a[10];

Now there is no internal linkage. Where does the composite type of the array become known? What does the phrase of the standard "the behavior is exactly as if the translation unit contains a file scope declaration of that identifier, with the composite type" mean in this case? What is this mysterious behavior?

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

#1564

On 2012-08-20, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
> I do not like answers that starts with "I think' (without any offence).
> You think such a way others think aother way. Do we deal with a standard or not?
> Well, let change the original example the following way
>
> #include <stdio.h>
>
> int a[];
>
> int main( void )
> {
>    printf( "sizeof( a ) = %ul\n", sizeof( a ) );  

Nit: the format specifier to print an unsigned long is
"%lu", not "%ul". "%ul" will print an unsigned int, followed
by the letter "l".

>    return ( 0 );
> }
>
> int a[10];
>
> Now there is no internal linkage. Where does the composite type of the
> array become known? What does the phrase of the standard "the behavior
> is exactly as if the translation unit contains a file scope
> declaration of that identifier, with the composite type" mean in this
> case? What is this mysterious behavior?

Before the first declaration, "a" is undeclared
and cannot be used in an expression.
Between the first and the second declarations,
"a" has an array type of unknown size, hence, an incomplete type,
so the occurrence if "sizeof a" at that point is an error.
The type of "a" is completed by the second declaration.

Both declarations serve as a tentative definition. Neither
of the declarations has an initializer, so there is no (explicit)
external definition; that is where 6.9.2 p2 applies, and an
(implicit) external definition as assumed. The type of this
external definition is the composite type of
the tentative definitions, with a zero initializer.

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

#1567

Am 20.08.2012 14:27, schrieb Ike Naar:
> On 2012-08-20, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
>> I do not like answers that starts with "I think' (without any offence).
>> You think such a way others think aother way. Do we deal with a standard or not?
>> Well, let change the original example the following way
>>
>> #include <stdio.h>
>>
>> int a[];
>>
>> int main( void )
>> {
>>    printf( "sizeof( a ) = %ul\n", sizeof( a ) );  
> 
> Nit: the format specifier to print an unsigned long is
> "%lu", not "%ul". "%ul" will print an unsigned int, followed
> by the letter "l".

Nit for nit, sizeof is of type size_t and the correct format for that is
%zu and not %lu

Jens

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

#1568

On 2012-08-20, Jens Gustedt <jens.gustedt@loria.fr> wrote:
> Am 20.08.2012 14:27, schrieb Ike Naar:
>> On 2012-08-20, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
>>>    printf( "sizeof( a ) = %ul\n", sizeof( a ) );  
>> 
>> Nit: the format specifier to print an unsigned long is
>> "%lu", not "%ul". "%ul" will print an unsigned int, followed
>> by the letter "l".
>
> Nit for nit, sizeof is of type size_t and the correct format for that is
> %zu and not %lu

Indeed, "%zu" would be the preferred format for a size_t.
However "%zu" was introduced in the C1999 standard; if Vlad from
Moscow is stuck with a pre-C1999 compiler, a workable alternative
would be to cast the size_t to unsigned long and use the "%lu" format.

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

#1569

Am 20.08.2012 18:35, schrieb Ike Naar:
> Indeed, "%zu" would be the preferred format for a size_t.
> However "%zu" was introduced in the C1999 standard; if Vlad from
> Moscow is stuck with a pre-C1999 compiler, a workable alternative
> would be to cast the size_t to unsigned long and use the "%lu" format.

This is comp.std.c and not comp.lang.c, here we discuss the standard and
not problems that a user might have with a particular implementation :)

Jens

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

#1565

On 08/19/2012 07:42 PM, Vlad from Moscow wrote:
> понедельник, 20 августа 2012 г., 1:56:49 UTC+4 пользователь Ike Naar написал:
>> On 2012-08-19, Vlad from Moscow <vlad.moscow@mail.ru> wrote:
>>
>>>> Vlad from Moscow <> writes:
>>>>> Let consider a sample code
>>>>>     #include <stdio.h>    
>>>>>     static int a[];
>>>>>     int main( void )
>>>>>     {
>>>>>        printf( "sizeof( a ) = %ul\n", sizeof( a ) );
>>>>>        return 0;
>>>>>     }
>>>>>     extern int a[10];
>>>>
>>>>> Shall a compiler issue an error for this sample code? Or the composite
>>>>> type of the array 'a' shall be known already in the point where the
>>>>> printf is used?
>>>
>>> According to paragraph 2 of section 6.9.2 External object definitions
>>> "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."
>>
>>   static int a[];
>>
>> violates 6.9.2 p3:
>>
>> "If the declaration of an identifier for an object is a tentative
>> definition and has internal linkage, the declared type shall not be
>> an incomplete type."
> 
> I understand paragraph #2 of section 6.9.2 External object definitions that says that "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." 
> that in my sample the array has complete composite type int [10].

That doesn't affect the applicability of 6.9.2p3; it's still a
constraint violation for you have both static and [] in that
declaration; you must remove one or the other. Given the main question
you've been asking, I'll assume that 'static' is the one that should be
removed.

The key thing that paragraph is talking about is the "initializer equal
to 0". What it means is that your program behaves exactly the same as if
there had been an additional declaration, at the end of the translation
unit, like the following:

	int a[10] = {0};

It does NOT mean that the program acts as though such a declaration had
been inserted at the beginning of the translation unit, which is where
it would have to have been inserted to make your sizeof expression
acceptable. The scope of the identifier "a" does not start until the
first declaration, and it does not have a complete type until the second
declaration. It has an initializer only because of the implicitly
generated third declaration.
-- 
James Kuyper

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

#1551

понедельник, 20 августа 2012 г., 0:40:34 UTC+4 пользователь Vlad from Moscow написал:
> Let consider a sample code
> 
> 
> 
> #include <stdio.h>
> 
> 
> 
> static int a[];
> 
> 
> 
> int main( void )
> 
> {
> 
>    printf( "sizeof( a ) = %ul\n", sizeof( a ) );
> 
> 
> 
>    return 0;
> 
> }
> 
> 
> 
> extern int a[10];
> 
> 
> 
> Shall a compiler issue an error for this sample code? Or the composite type of the array 'a' shall be known already in the point where the printf is used?

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

#1553

On Sun, 19 Aug 2012, Vlad from Moscow wrote:

> Let consider a sample code
>
> #include <stdio.h>
>
> static int a[];

This seems to violate C99 6.9.2p3.

Let's assume "int a[]" here...

>
> int main( void )
> {
>   printf( "sizeof( a ) = %ul\n", sizeof( a ) );
>
>   return 0;
> }
>
> extern int a[10];

...and "int a[10]" here (the quoted declaration is not a tentative 
definition, 6.9.2p2).

>
> Shall a compiler issue an error for this sample code? Or the composite 
> type of the array 'a' shall be known already in the point where the 
> printf is used?

6.9.2p2 defines the composite type. It doesn't attempt (nor has to) define 
the "location" of the single "as-if" declaration; the "behavior" is meant 
for ("restricted to") the purposes of 6.9 External definitions.

According to 6.2.5p22, 6.5.3.4p1 and 5.1.1.3p1, a diagnostic message shall 
be produced.

Laszlo

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

#1554

понедельник, 20 августа 2012 г., 1:36:41 UTC+4 пользователь Ersek, Laszlo написал:
> On Sun, 19 Aug 2012, Vlad from Moscow wrote:
> 
> 
> 
> > Let consider a sample code
> 
> >
> 
> > #include <stdio.h>
> 
> >
> 
> > static int a[];
> 
> 
> 
> This seems to violate C99 6.9.2p3.
> 
> 
> 
> Let's assume "int a[]" here...
> 
> 
> 
> >
> 
> > int main( void )
> 
> > {
> 
> >   printf( "sizeof( a ) = %ul\n", sizeof( a ) );
> 
> >
> 
> >   return 0;
> 
> > }
> 
> >
> 
> > extern int a[10];
> 
> 
> 
> ...and "int a[10]" here (the quoted declaration is not a tentative 
> 
> definition, 6.9.2p2).
> 
> 
> 
> >
> 
> > Shall a compiler issue an error for this sample code? Or the composite 
> 
> > type of the array 'a' shall be known already in the point where the 
> 
> > printf is used?
> 
> 
> 
> 6.9.2p2 defines the composite type. It doesn't attempt (nor has to) define 
> 
> the "location" of the single "as-if" declaration; the "behavior" is meant 
> 
> for ("restricted to") the purposes of 6.9 External definitions.
> 
> 
> 
> According to 6.2.5p22, 6.5.3.4p1 and 5.1.1.3p1, a diagnostic message shall 
> 
> be produced.
> 
> 
> 
> Laszlo

I have not understood why you wrote "Let's assume "int a[]" here..." when in my sample code there is already written

static int a[];

[toc] | [prev] | [standalone]

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

csiph-web