Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Why is initializing a FAM invalid?

Reply
Thread Tools

Why is initializing a FAM invalid?

 
 
Marcin Grzegorczyk
Guest
Posts: n/a
 
      11-08-2010
Seebs wrote:
> On 2010-11-08, Wojtek Lerch<(E-Mail Removed)> wrote:
>> To answer my own question, sizeof does not include the FAM. The analogy
>> with arrays of unknown size is bogus.

>
> There was some quirk to do with sizeof(foo) vs. offsetof(struct foo, fam)
> where something changed in one of the TCs.


You're thinking of DR #282 (fixed in TC2), I guess.
--
Marcin Grzegorczyk
 
Reply With Quote
 
 
 
 
Wojtek Lerch
Guest
Posts: n/a
 
      11-08-2010
"Marcin Grzegorczyk" <(E-Mail Removed)> wrote in message
news:ib9jl4$mec$(E-Mail Removed)-september.org...
> Wojtek Lerch wrote:
>> "Wojtek Lerch" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> "Marcin Grzegorczyk" <(E-Mail Removed)> wrote in message
>>> news:ib4h3f$g0j$(E-Mail Removed)-september.org...
>>>> Of course, the compiler could postpone structure allocation until it
>>>> has seen the whole initializer list -- much like it has to do when
>>>> initializing an array of unknown size. GCC, for example, allows FAM
>>>> initialization as an extension.
>>>
>>> What does sizeof return when applied to the name of such object?

>>
>> To answer my own question, sizeof does not include the FAM. The analogy
>> with arrays of unknown size is bogus.

>
> The analogy was supposed to apply to how a compiler determines the size of
> an object, and my point was that there are situations where the size is
> known only after the initialization has been parsed.


But even that analogy is not very good: in the case of normal arrays, the
initializer determines the *type* of the object, and then the size follows
from the type in the usual way. In the case of a structure with a FAM, the
type of the object is the struct, and the size of that type does not include
the array (or at least not necessarily all of it). Since the size of the
object, as reported by sizeof, doesn't include the array either, one could
argue that the array doesn't really belong to the declared object, but to a
larger unnamed object that contains both the struct and the array. (That's,
BTW, more or less how this extension is explained by GCC documentation.)

Presumably the assignment operator agress with sizeof about how many bytes
need to be copied?

> This does not
> have to do anything with sizeof.


Other than the fact that sizeof is supposed to report the size of the
object.



 
Reply With Quote
 
 
 
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      11-08-2010
Wojtek Lerch wrote:

> "Marcin Grzegorczyk" <(E-Mail Removed)> wrote in message
> news:ib4h3f$g0j$(E-Mail Removed)-september.org...
>> Of course, the compiler could postpone structure allocation until it has
>> seen the whole initializer list -- much like it has to do when
>> initializing an array of unknown size. GCC, for example, allows FAM
>> initialization as an extension.

>
> What does sizeof return when applied to the name of such object? Will
> se0, se1 and se2 all have the same value in this example:
>
> extern struct s { int x; int d[]; } e;
> size_t se0 = sizeof(struct s);
> size_t se1 = sizeof e;
> struct s e = { 0, { 1, 2 } };
> size_t se2 = sizeof e;


From the C99 wording it follows that the size is as if the FAM is omitted,
except that it may have more trailing padding than the omission would imply.

Easy matter dude
 
Reply With Quote
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      11-08-2010
Wojtek Lerch wrote:

> "Marcin Grzegorczyk" <(E-Mail Removed)> wrote in message
> news:ib9jl4$mec$(E-Mail Removed)-september.org...
>> Wojtek Lerch wrote:
>>> "Wojtek Lerch" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> "Marcin Grzegorczyk" <(E-Mail Removed)> wrote in message
>>>> news:ib4h3f$g0j$(E-Mail Removed)-september.org...
>>>>> Of course, the compiler could postpone structure allocation until it
>>>>> has seen the whole initializer list -- much like it has to do when
>>>>> initializing an array of unknown size. GCC, for example, allows FAM
>>>>> initialization as an extension.
>>>>
>>>> What does sizeof return when applied to the name of such object?
>>>
>>> To answer my own question, sizeof does not include the FAM. The analogy
>>> with arrays of unknown size is bogus.

>>
>> The analogy was supposed to apply to how a compiler determines the size
>> of an object, and my point was that there are situations where the size
>> is known only after the initialization has been parsed.

>
> But even that analogy is not very good: in the case of normal arrays, the
> initializer determines the *type* of the object, and then the size follows
> from the type in the usual way. In the case of a structure with a FAM,
> the type of the object is the struct, and the size of that type does not
> include
> the array (or at least not necessarily all of it). Since the size of the
> object, as reported by sizeof, doesn't include the array either, one could
> argue that the array doesn't really belong to the declared object, but to
> a
> larger unnamed object that contains both the struct and the array.
> (That's, BTW, more or less how this extension is explained by GCC
> documentation.)
>


I think the C99 Standard makes no difference between non-subobjects and
subobjects. It just says

"Each brace-enclosed initializer list has an associated current object. When
no designations are present, subobjects of the current object are
initialized in order according to the type of the current object [...]"

"If an array of unknown size is initialized, its size is determined by the
largest indexed element with an explicit initializer. At the end of its
initializer list, the array no longer has incomplete type."

I think this states that the FAM's size is correctly determined by that
procedure.

>
>> This does not
>> have to do anything with sizeof.

>
> Other than the fact that sizeof is supposed to report the size of the
> object.


It can't report the size of objects, because that is only known at runtime.
It therefor only reports "from the type of the operand.".
 
Reply With Quote
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      11-08-2010
Wojtek Lerch wrote:

> "Marcin Grzegorczyk" <(E-Mail Removed)> wrote in message
> news:ib9jl4$mec$(E-Mail Removed)-september.org...
>> Wojtek Lerch wrote:
>>> "Wojtek Lerch" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> "Marcin Grzegorczyk" <(E-Mail Removed)> wrote in message
>>>> news:ib4h3f$g0j$(E-Mail Removed)-september.org...
>>>>> Of course, the compiler could postpone structure allocation until it
>>>>> has seen the whole initializer list -- much like it has to do when
>>>>> initializing an array of unknown size. GCC, for example, allows FAM
>>>>> initialization as an extension.
>>>>
>>>> What does sizeof return when applied to the name of such object?
>>>
>>> To answer my own question, sizeof does not include the FAM. The analogy
>>> with arrays of unknown size is bogus.

>>
>> The analogy was supposed to apply to how a compiler determines the size
>> of an object, and my point was that there are situations where the size
>> is known only after the initialization has been parsed.

>
> But even that analogy is not very good: in the case of normal arrays, the
> initializer determines the *type* of the object, and then the size follows
> from the type in the usual way. In the case of a structure with a FAM,
> the type of the object is the struct, and the size of that type does not
> include
> the array (or at least not necessarily all of it). Since the size of the
> object, as reported by sizeof, doesn't include the array either, one could
> argue that the array doesn't really belong to the declared object, but to
> a
> larger unnamed object that contains both the struct and the array.
> (That's, BTW, more or less how this extension is explained by GCC
> documentation.)
>


I think the C99 Standard makes no difference between non-subobjects and
subobjects. It just says

"Each brace-enclosed initializer list has an associated current object. When
no designations are present, subobjects of the current object are
initialized in order according to the type of the current object [...]"

"If an array of unknown size is initialized, its size is determined by the
largest indexed element with an explicit initializer. At the end of its
initializer list, the array no longer has incomplete type."

I think this states that the FAM's size is correctly determined by that
procedure.

>
>> This does not
>> have to do anything with sizeof.

>
> Other than the fact that sizeof is supposed to report the size of the
> object.


It can't report the size of objects, because that is only known at runtime.
It therefor only reports "from the type of the operand.".
 
Reply With Quote
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      11-08-2010
Wojtek Lerch wrote:

> "Marcin Grzegorczyk" <(E-Mail Removed)> wrote in message
> news:ib4h3f$g0j$(E-Mail Removed)-september.org...
>> Of course, the compiler could postpone structure allocation until it has
>> seen the whole initializer list -- much like it has to do when
>> initializing an array of unknown size. GCC, for example, allows FAM
>> initialization as an extension.

>
> What does sizeof return when applied to the name of such object? Will
> se0, se1 and se2 all have the same value in this example:
>
> extern struct s { int x; int d[]; } e;
> size_t se0 = sizeof(struct s);
> size_t se1 = sizeof e;
> struct s e = { 0, { 1, 2 } };
> size_t se2 = sizeof e;


From the C99 wording it follows that the size is as if the FAM is omitted,
except that it may have more trailing padding than the omission would imply.

Easy matter dude
 
Reply With Quote
 
Wojtek Lerch
Guest
Posts: n/a
 
      11-09-2010
On 08/11/2010 6:08 PM, Johannes Schaub (litb) wrote:
> Wojtek Lerch wrote:
>> "Marcin Grzegorczyk"<(E-Mail Removed)> wrote in message
>> news:ib9jl4$mec$(E-Mail Removed)-september.org...
>>> Wojtek Lerch wrote:
>>>> "Wojtek Lerch"<(E-Mail Removed)> wrote in message
>>>> news:(E-Mail Removed)...
>>>>> "Marcin Grzegorczyk"<(E-Mail Removed)> wrote in message
>>>>> news:ib4h3f$g0j$(E-Mail Removed)-september.org...
>>>>>> [...] GCC, for example, allows FAM
>>>>>> initialization as an extension. [...]
>>>>>
>>>>> What does sizeof return when applied to the name of such object?
>>>>
>>>> To answer my own question, sizeof does not include the FAM. The analogy
>>>> with arrays of unknown size is bogus.
>>>
>>> The analogy was supposed to apply to how a compiler determines the size
>>> of an object, and my point was that there are situations where the size
>>> is known only after the initialization has been parsed.

>>
>> But even that analogy is not very good: in the case of normal arrays, the
>> initializer determines the *type* of the object, and then the size follows
>> from the type in the usual way. In the case of a structure with a FAM,
>> the type of the object is the struct, and the size of that type does not
>> include
>> the array (or at least not necessarily all of it). Since the size of the
>> object, as reported by sizeof, doesn't include the array either, one could
>> argue that the array doesn't really belong to the declared object, but to
>> a
>> larger unnamed object that contains both the struct and the array.
>> (That's, BTW, more or less how this extension is explained by GCC
>> documentation.)

>
> I think the C99 Standard [...]


You do realize that the discussion was not about a standard feature, but
a GCC extension, right?

> [...] makes no difference between non-subobjects and
> subobjects. It just says
>
> "Each brace-enclosed initializer list has an associated current object. When
> no designations are present, subobjects of the current object are
> initialized in order according to the type of the current object [...]"


Um... It says "subobjects" right there, and doesn't mention
non-subobjects. Is that not a difference?

> "If an array of unknown size is initialized, its size is determined by the
> largest indexed element with an explicit initializer. At the end of its
> initializer list, the array no longer has incomplete type."
>
> I think this states that the FAM's size is correctly determined by that
> procedure.


Does it? What is the type of the FAM before and after the initializer?

>>> This does not
>>> have to do anything with sizeof.

>>
>> Other than the fact that sizeof is supposed to report the size of the
>> object.

>
> It can't report the size of objects, because that is only known at runtime.
> It therefor only reports "from the type of the operand.".


Right. But does that mean that an object declared using the GCC
extension is bigger than its type, or does it mean that the declared
object is the size of its type but is a subobject of a bigger, unnamed
object that the compiler allocates to accommodate for the initialized
FAM? The documentation is not completely clear on that, and of course
C99 is silent on the matter.
 
Reply With Quote
 
Wojtek Lerch
Guest
Posts: n/a
 
      11-09-2010
On 08/11/2010 6:08 PM, Johannes Schaub (litb) wrote:
> Wojtek Lerch wrote:
>> "Marcin Grzegorczyk"<(E-Mail Removed)> wrote in message
>> news:ib4h3f$g0j$(E-Mail Removed)-september.org...
>>> [...] GCC, for example, allows FAM
>>> initialization as an extension.

>>
>> What does sizeof return when applied to the name of such object? Will
>> se0, se1 and se2 all have the same value in this example:
>>
>> extern struct s { int x; int d[]; } e;
>> size_t se0 = sizeof(struct s);
>> size_t se1 = sizeof e;
>> struct s e = { 0, { 1, 2 } };
>> size_t se2 = sizeof e;

>
> From the C99 wording it follows that the size is as if the FAM is omitted,
> except that it may have more trailing padding than the omission would imply.


I thought that from the C99 wording it follows that the above is a
constraint violation.

> Easy matter dude


 
Reply With Quote
 
Marcin Grzegorczyk
Guest
Posts: n/a
 
      11-10-2010
Wojtek Lerch wrote:
> "Marcin Grzegorczyk" <(E-Mail Removed)> wrote in message
> news:ib9jl4$mec$(E-Mail Removed)-september.org...
>> Wojtek Lerch wrote:
>>> To answer my own question, sizeof does not include the FAM. The analogy
>>> with arrays of unknown size is bogus.

>>
>> The analogy was supposed to apply to how a compiler determines the
>> size of an object, and my point was that there are situations where
>> the size is known only after the initialization has been parsed.

>
> But even that analogy is not very good: in the case of normal arrays,
> the initializer determines the *type* of the object, and then the size
> follows from the type in the usual way. In the case of a structure with
> a FAM, the type of the object is the struct, and the size of that type
> does not include the array (or at least not necessarily all of it).
> Since the size of the object, as reported by sizeof, doesn't include the
> array either, one could argue that the array doesn't really belong to
> the declared object, but to a larger unnamed object that contains both
> the struct and the array.


Yeah, that's more or less what 6.7.2.1p16 seems to imply.

When I said "the size of an object" above, I meant the size allocated by
the compiler (because that was what the post to which I was originally
replying mentioned), not the size defined by the semantics of C99. They
need not be the same.

> Presumably the assignment operator agress with sizeof about how many
> bytes need to be copied?


This seems to be implied by the "in most situations, the flexible array
member is ignored" wording, too. Note that the assignment operator is
allowed to copy structures member-by-member instead of byte-by-byte
(though most compilers choose the latter).
--
Marcin Grzegorczyk
 
Reply With Quote
 
Michael Foukarakis
Guest
Posts: n/a
 
      11-10-2010
On Nov 5, 11:01*pm, "Johannes Schaub (litb)" <(E-Mail Removed)>
wrote:
> The C99 Standard at 6.7.2.1/18 says the following is invalid
>
> * * struct s { int x; int d[]; } e = { 0, { 1, 2 } };
>
> "because struct s is treated as if it did not contain member d.". I
> understand that this is just non-normative example text, so I was looking
> for normative text about it. 6.7.8 about initialization does not state that
> FAMs are ignored. Where is such a thing stated? 6.7.2.1/16 says "In most
> situations, the flexible array member is ignored.", which doesn't forbid the
> initialization either.


One purpose FAMs can fulfill is mapping structures over data, for
examples network packet headers over network data, intended for
analysis. In those cases, pre-FAM, one would declare a pointer inside
the structure and made sure it pointed to the right spot. I suppose
I'm thinking of this use case of FAMs like a convenience for
addressing over memory that is allocated by "someone else". The
problem here, as I see it, is that {1, 2} has no memory allocated for
it, and is therefore impossible to initialize the struct with it.

My quibble is why

struct s { int x; char d[]; } e = { 0, "foo" };

produces the same error, as there is at least one way to resolve it
without conflicting with the wording of the standard.

2c
 
Reply With Quote
 
 
 
Reply

Thread Tools

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

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


Similar Threads
Thread Thread Starter Forum Replies Last Post
python-fam documentation. Shriphani Python 2 07-26-2007 12:39 AM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
[ANN] FAM-Ruby 0.2.0 Paul Duncan Ruby 0 12-20-2006 11:25 AM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Why no compiler-warning at invalid array-initializing ? carlos@gkpwdun.com Java 11 11-07-2005 08:34 PM



Advertisments