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

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

How does strict aliasing work with parallel arrays in a union or const-initialized data

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

Contents

  How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-10-21 16:47 -0700
    Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-24 21:20 -0700
      Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-10-25 11:44 -0700
        Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 12:15 -0700
          Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-10-28 14:25 -0700
            Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Keith Thompson <kst-u@mib.org> - 2015-10-28 16:23 -0700
              Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 17:08 -0700
                Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Keith Thompson <kst-u@mib.org> - 2015-10-28 18:09 -0700
                  Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-10-28 20:02 -0700
                    Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Bartc <bc@freeuk.com> - 2015-10-29 10:55 +0000
                      Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-10-29 06:50 -0700
                      Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Keith Thompson <kst-u@mib.org> - 2015-10-29 08:52 -0700
                      Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-10-31 10:21 -0700
                    Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Keith Thompson <kst-u@mib.org> - 2015-10-29 08:50 -0700
                      Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-10-29 12:25 -0700
                  Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 13:02 -0700
                    Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Keith Thompson <kst-u@mib.org> - 2015-10-30 13:35 -0700
                      Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 19:57 -0700
                        Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Keith Thompson <kst-u@mib.org> - 2015-10-31 12:27 -0700
                  Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-30 17:02 -0400
                    Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Keith Thompson <kst-u@mib.org> - 2015-10-30 14:16 -0700
                    Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-10-31 08:13 -0700
                      Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-31 08:42 -0700
                        Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-10-31 10:40 -0700
                          Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-02 01:45 -0800
                            Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-11-02 06:57 -0800
                              Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-02 08:12 -0800
                                Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-11-02 08:54 -0800
                                  Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-04 07:24 -0800
                                    Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-11-04 09:22 -0800
                                      Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-04 19:48 -0800
                                        Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-11-05 09:44 -0800
                                          Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-07 10:17 -0800
                                          Re: How does strict aliasing work with parallel arrays in a union or const-initialized data raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:37 +0000
                                            Re: How does strict aliasing work with parallel arrays in a union or const-initialized data supercat@casperkitty.com - 2015-11-10 09:01 -0800
            Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 16:48 -0700
          Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Keith Thompson <kst-u@mib.org> - 2015-10-28 16:11 -0700
            Re: How does strict aliasing work with parallel arrays in a union or const-initialized data Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 16:37 -0700

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

#74369

Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> On 10/28/2015 9:09 PM, Keith Thompson wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>
>>>> supercat@casperkitty.com writes:
>>>>> On Wednesday, October 28, 2015 at 2:15:29 PM UTC-5, Tim Rentsch wrote:
>>>>>> supercat writes:
>>>>>>> [snip]
>>>>>
>>>>> If I have one translation unit which contains the definitions:
>>>>>
>>>>>     struct FOO { int x,y; char b[]; };
>>>>>     struct GOO { int x,y; char b[4]; };
>>>>>  [...]
>>
>> Right.  I was thinking of the more general case of two distinct struct
>> types with a common initial subsequence.  I missed the fact that struct
>> FOO and struct GOO are compatible.
>
> 	$ cat foo.c
> 	struct FOO { int x,y; char b[]; };
> 	struct GOO { int x,y; char b[4]; };
> 	int main(void) {
> 	   struct FOO f;
> 	   struct GOO g;
> 	   f = g;
> 	   return 0;
> 	}
> 	$ gcc -std=c99 foo.c
> 	foo.c: In function ‘main’:
> 	foo.c:6:6: error: incompatible types when assigning to type ‘struct 
> FOO’ from type ‘struct GOO’
> 	    f = g;
> 	      ^
>
> (Stupid gcc!)

Smart gcc, actually.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#74437

On Friday, October 30, 2015 at 4:02:23 PM UTC-5, Eric Sosman wrote:
> 	foo.c:6:6: error: incompatible types when assigning to type 'struct 
> FOO' from type 'struct GOO'

There's a difference between being type-compatible and being layout-compatible.
I never claimed type compatibility; the question would be whether the layouts
would be the same.  From what I can tell, nothing would forbid a C compiler
from varying the offset of an array within a struct based upon the size thereof
even though there's a lot of code which can't possibly hope to work right if
array offsets do in fact vary.

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

#74442

supercat@casperkitty.com writes:

> On Friday, October 30, 2015 at 4:02:23 PM UTC-5, Eric Sosman wrote:
>> 	foo.c:6:6: error: incompatible types when assigning to type 'struct 
>> FOO' from type 'struct GOO'
>
> There's a difference between being type-compatible and being
> layout-compatible.  I never claimed type compatibility;  the
> question would be whether the layouts would be the same.  From
> what I can tell, nothing would forbid a C compiler from varying
> the offset of an array within a struct based upon the size thereof
> [snip]

Have you taken into account the implications of 6.5.2.3 p6 (or p5
in N1256) considered in conjunction with flexible array members?

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

#74454

On Saturday, October 31, 2015 at 10:42:26 AM UTC-5, Tim Rentsch wrote:
> Have you taken into account the implications of 6.5.2.3 p6 (or p5
> in N1256) considered in conjunction with flexible array members?

The footnote suggested that previously, given:

    struct S1a { int i; char x,y[4]; };
    struct S1b { int i; char x,y[4]; };
    struct S2  { int i; char x,y[2]; };
    union { S1a s1a; S1b s1b; S2 s2; } u;

the offsets of u.s1a.y and u.s1b.y would have had to be equal, but the
offset of u.s2.y could have been different.  If that is the case, what
would imply that adding:

    struct S3  { int i; char x,y[]; } u2;
    union { S1a s1a; S1b s1b; S2 s2; S3 s3;} u;

to the mix would not allow the offset of u2.s3.y to be something else?  I
would not be at all surprised if, before C99 was published, some compilers
would have laid out the structures as:

    s1* : i@(0..3) x=4, y=(5..8) size=12
    s2  : i@(0..3) x=4, y=(5..6) size=8
    s3  : i@(0..3) x=4, y=8+     size=8

while others perhaps as:

    s1* : i@(0..3) x=4, y=(5..8) size=12
    s2  : i@(0..3) x=4, y=(5..6) size=8
    s3  : i@(0..3) x=4, y=5+     size=5 [*NOT* a multiple of alignment!]

or maybe even something fun like:

    s1* : i@(0..3) x=4, y=(8..11) size=12
    s2  : i@(0..3) x=4, y=(6..7)  size=8
    s3  : i@(0..3) x=4, y=5+      size=5 [*NOT* a multiple of alignment!]

and I don't think the Committee wanted to invalidate any such behaviors and
thus break any code that relied upon them.  [Incidentally, it is because
of things like this that I think the Committee should more pro-actively work
on developing optional features, though it needs to make sure that with each
feature it provides a means by which programs can test availability; if the
Committee waits until compiler writers add a feature before it says how such
a thing should work, it's like that compiler writers will end up using the
same syntax to mean slightly-different things, thus creating nasty problems
going forward].

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

#74628

supercat@casperkitty.com writes:

> On Saturday, October 31, 2015 at 10:42:26 AM UTC-5, Tim Rentsch wrote:
>>supercat@casperkitty.com writes:
>>
>>> From what I can tell, nothing would forbid a C compiler from
>>> varying the offset of an array within a struct based upon the
>>> size thereof [snip]
>>
>> Have you taken into account the implications of 6.5.2.3 p6 (or p5
>> in N1256) considered in conjunction with flexible array members?
>
> The footnote suggested that previously, [snip]

My question was about normative text only.

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

#74649

On Monday, November 2, 2015 at 3:45:47 AM UTC-6, Tim Rentsch wrote:
> supercat writes:
> 
> > On Saturday, October 31, 2015 at 10:42:26 AM UTC-5, Tim Rentsch wrote:
> >> Have you taken into account the implications of 6.5.2.3 p6 (or p5
> >> in N1256) considered in conjunction with flexible array members?
> >
> > The footnote suggested that previously, [snip]
> 
> My question was about normative text only.

For purposes of that section, are different size arrays considered to be
the same type, subject to the same layout handling?  Many compilers treat
them as such, but parts of the text only make sense if compilers would
be allowed to treat different array sizes differently.

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

#74658

supercat@casperkitty.com writes:

> On Monday, November 2, 2015 at 3:45:47 AM UTC-6, Tim Rentsch wrote:
>> supercat writes:
>>
>>> On Saturday, October 31, 2015 at 10:42:26 AM UTC-5, Tim Rentsch wrote:
>>>> Have you taken into account the implications of 6.5.2.3 p6 (or p5
>>>> in N1256) considered in conjunction with flexible array members?
>>>
>>> The footnote suggested that previously, [snip]
>>
>> My question was about normative text only.
>
> For purposes of that section, are different size arrays considered to be
> the same type, subject to the same layout handling?  Many compilers treat
> them as such, but parts of the text only make sense if compilers would
> be allowed to treat different array sizes differently.

Consider two struct types

    struct F  {  int x;  char flexible[];  };
    struct R4 {  int x;  char rigid_4[4];  };

Are the members 'flexible' and 'rigid_4' part of the common initial
sequence for the two struct types?  Note that the types of the two
members are compatible.

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

#74664

On Monday, November 2, 2015 at 10:12:16 AM UTC-6, Tim Rentsch wrote:
> Consider two struct types
> 
>     struct F  {  int x;  char flexible[];  };
>     struct R4 {  int x;  char rigid_4[4];  };
> 
> Are the members 'flexible' and 'rigid_4' part of the common initial
> sequence for the two struct types?  Note that the types of the two
> members are compatible.

Are you asking me?  I was trying to ask you that.  Prior to having read the
footnote, I would have said the answer was "yes", but been confused with
regard to the purpose of some apparently-meaningless language in the
Standard.  The footnote suggests that the answer is "no", and regarding the
answer as being "no" makes the clear purpose of the language which had been
confusing.

It has certainly been common historically for compilers to lay out two or
more consecutive arrays of the same type within a struct as though the first
field identified an array with the combined size, and the second identified
a starting location within it, and that pattern would suggest that given:

>     struct R2 {  int x;  char arr[2];  };
>     struct R4 {  int x;  char arr[4];  };
    
the common initial sequence of the two structures would extend through the
second element of arr.  Unfortunately, even though the vast majority of
compilers work that way, and even though there is a lot of code which has
no realistic possibility of working on any compiler which lays out their
structures differently, I don't think there's any means via which code can
enforce such behavior except perhaps via compile-time assert on __offsetof
values.

Would that fit your interpretation?  If so, can you see any guaranteed-useful
way to perform compile-time initialization of something that's usable as a
structure with a flexible array member [if an FAM wouldn't be considered part
of the same initial sequence as a fixed-size array, the union trick would not
be sufficient].

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

#74849

supercat@casperkitty.com writes:

> On Monday, November 2, 2015 at 10:12:16 AM UTC-6, Tim Rentsch wrote:
>> Consider two struct types
>>
>>     struct F  {  int x;  char flexible[];  };
>>     struct R4 {  int x;  char rigid_4[4];  };
>>
>> Are the members 'flexible' and 'rigid_4' part of the common initial
>> sequence for the two struct types?  Note that the types of the two
>> members are compatible.
>
> Are you asking me?

Sure.  It's time to play in the big leagues.  :)

> I was trying to ask you that.  Prior to having read the footnote,
> I would have said the answer was "yes", but been confused with
> regard to the purpose of some apparently-meaningless language in
> the Standard.

Grammatical nit:  no hypenation for "apparently meaningless".
Because "apparently" is an adverb, it must modify the adjective
"meaningless", so there is no ambiguity to resolve.

> The footnote suggests that the answer is "no", and regarding the
> answer as being "no" makes the clear purpose of the language which
> had been confusing.

The footnote (besides being informative rather than normative) I
think you are referencing is moot, since it was removed from the
Standard by a C99 Technical Corrigendum.

> It has certainly been common historically for compilers to
> [snip] 

That has no bearing on the question, which is only about what the
Standard does or does not stipulate.

> [C]an you see any guaranteed-useful way to [snip]

The first step to answering that question is to determine whether
the provisions of 6.5.2.3 p6 (or p5 in N1256) are in force for
flexible array members.  To do that reliably, ultimtely you will
have to read the Standard (and perhaps other documents) and
decide for yourself - perhaps with the aid of some discussion
here in the newsgroup, but eventually it has to come down to
what you think ISO C requires (or not) of implementations in
such cases, not just what other people think.

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

#74856

On Wednesday, November 4, 2015 at 9:24:18 AM UTC-6, Tim Rentsch wrote:
> Grammatical nit:  no hypenation for "apparently meaningless".
> Because "apparently" is an adverb, it must modify the adjective
> "meaningless", so there is no ambiguity to resolve.

Hyphens are generally inappropriate when using adverbs to modify predicate
adjectives, but often improve parsing and prosody when used to join adverbs
with adjectives in other contexts.  I believe I considered the text with
and without the hyphen and decided it parsed better with.

> > The footnote suggests that the answer is "no", and regarding the
> > answer as being "no" makes the clear purpose of the language which
> > had been confusing.
> 
> The footnote (besides being informative rather than normative) I
> think you are referencing is moot, since it was removed from the
> Standard by a C99 Technical Corrigendum.

Neither the existence of implementations which vary the alignment of arrays
based upon the number of elements therein, nor the Standard's authors'
awareness of such implementations is dependent upon the presence or absence
of the footnote.

If such implementations were merely a figment of the imagination of whoever
write the footnote, and the authors of the Standard do not believe that
such implementations exist or would be compliant, the Standard should have
made mention of that.  Its failure to do so suggests that the authors of
the Standard believe such implementations exist.

If such implementations exist and the authors are aware of them, the fact
that the authors have not added language indicating that they are forbidden
should be taken as an implication that the authors intend to allow for such
implementations.  I fail to see how the removal of the footnote would negate
that implication.

I would further posit that since many reasonable people have certainly
believed that the Standard requires that if two structures have arrays
which follow a perfectly-matched initial sequence, and the arrays differ
only in their outermost dimension, the elements of the smaller array are
to be considered part of the structures' common initial sequence,
overlapping corresponding elements in the larger.  If such a believe if
contrary to the intention of the Standard, the fact that many reasonable
people would misconstrue the Standards' intention is prima facie evidence
that the Standard is defective.

> > It has certainly been common historically for compilers to
> > [snip] 
> 
> That has no bearing on the question, which is only about what the
> Standard does or does not stipulate.

For the authors of the practice to indicate awareness of a practice without
saying that it is inconsistent with the Standard creates an implication that
the practice is consistent with the Standard.

> The first step to answering that question is to determine whether
> the provisions of 6.5.2.3 p6 (or p5 in N1256) are in force for
> flexible array members.  To do that reliably, ultimtely you will
> have to read the Standard (and perhaps other documents) and
> decide for yourself - perhaps with the aid of some discussion
> here in the newsgroup, but eventually it has to come down to
> what you think ISO C requires (or not) of implementations in
> such cases, not just what other people think.

I would posit that the Standard is defective, since it would allow compiler
writers to believe compilers are allowed to arbitrarily vary array-alignment
requirements based upon length, but would also allow reasonable programmers
to believe that compiler writers are not allowed to do so.

Such ambiguity could (and IMHO should) be resolved by defining various
directives macros to indicate what behavior is expected, with the
proviso that compilers would have three options with regard to their
expansion:

1. If the directive would imply the compiler's natural behavior, then the
   compiler may define it as an empty macro.

2. If the directive would imply an unsupported behavior, then the compiler
   may define it as something that forces a compilation error.

3. If the compiler supports multiple behaviors, the compiler may define the
   directive as an intrinsic that selects a particular behavior.

For example, given the declaration:

struct foo { uint32_t a; uint8_t b; uint16_t b[]; };

there are at least three semantically-sensible combinations of sizeof (foo)
and __offsetof(foo,b) that I can imagine compiler writers coming up with
prior to C99: [6,6], [8,8], and [8,6].  If the Standard were to say that
preceding the declaration with a certain macro would require a particular
behavior as follows:

  __STDC_SHORT_FAM_STRUCT would compel the first [offset of FAM is length
  of struct, but struct size need not be a multiple of struct alignment
  since it can't be used directly in cases requiring a known-size type]

  __STDC_PADDED_END_FAM_STRUCT would compel the second [structure is padded
  to its own alignment, and FAM coincides with the end]

  __STDC_INTERNAL_FAM_STRUCT would compel the third [structure is padded to
  its own alignment, but FAM offset is only padded to satisfy that member's
  alignment]

then any compiler could legitimately keep on having whichever behavior it had
started out using as its default, and would not be required to do anything
new for the new standard except to ignore the directive matching its existing
behavior and reject programs using the other ones, but would also have the
option to support any additional modes if desired, then there would be no
need to leave any ambiguity as to what was required for a given piece of code.

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

#74921

supercat@casperkitty.com writes:

> On Wednesday, November 4, 2015 at 9:24:18 AM UTC-6, Tim Rentsch wrote:
>> Grammatical nit:  no hypenation for "apparently meaningless".
>> Because "apparently" is an adverb, it must modify the adjective
>> "meaningless", so there is no ambiguity to resolve.
>
> Hyphens are generally inappropriate when using adverbs to modify
> predicate adjectives, but often improve parsing and prosody when
> used to join adverbs with adjectives in other contexts.  I believe
> I considered the text with and without the hyphen and decided it
> parsed better with.

Of course you can do what you want, but it's at odds with every
set of English usage rules I'm aware of.

>>> The footnote suggests that the answer is "no", and regarding the
>>> answer as being "no" makes the clear purpose of the language which
>>> had been confusing.
>>
>> The footnote (besides being informative rather than normative) I
>> think you are referencing is moot, since it was removed from the
>> Standard by a C99 Technical Corrigendum.
>
> Neither the existence of implementations which vary the alignment
> of arrays based upon the number of elements therein, nor the
> Standard's authors' awareness of such implementations is dependent
> upon the presence or absence of the footnote.
>
> If such implementations were merely a figment of the imagination
> of whoever write the footnote, and the authors of the Standard do
> not believe that such implementations exist or would be compliant,
> the Standard should have made mention of that.  Its failure to do
> so suggests that the authors of the Standard believe such
> implementations exist.
>
> If such implementations exist and the authors are aware of them,
> the fact that the authors have not added language indicating that
> they are forbidden should be taken as an implication that the
> authors intend to allow for such implementations.  I fail to see
> how the removal of the footnote would negate that implication.
>
> I would further posit that since many reasonable people have
> certainly believed that the Standard requires that if two
> structures have arrays which follow a perfectly-matched initial
> sequence, and the arrays differ only in their outermost dimension,
> the elements of the smaller array are to be considered part of the
> structures' common initial sequence, overlapping corresponding
> elements in the larger.  If such a believe if contrary to the
> intention of the Standard, the fact that many reasonable people
> would misconstrue the Standards' intention is prima facie evidence
> that the Standard is defective.
>
>>> It has certainly been common historically for compilers to
>>> [snip] 
>>
>> That has no bearing on the question, which is only about what the
>> Standard does or does not stipulate.
>
> For the authors of the practice to indicate awareness of a
> practice without saying that it is inconsistent with the Standard
> creates an implication that the practice is consistent with the
> Standard.
>
>> The first step to answering that question is to determine whether
>> the provisions of 6.5.2.3 p6 (or p5 in N1256) are in force for
>> flexible array members.  To do that reliably, ultimtely you will
>> have to read the Standard (and perhaps other documents) and
>> decide for yourself - perhaps with the aid of some discussion
>> here in the newsgroup, but eventually it has to come down to
>> what you think ISO C requires (or not) of implementations in
>> such cases, not just what other people think.
>
> I would posit that the Standard is defective, since it would allow
> compiler writers to believe compilers are allowed to arbitrarily
> vary array-alignment requirements based upon length, but would
> also allow reasonable programmers to believe that compiler writers
> are not allowed to do so.
>
> Such ambiguity could (and IMHO should) be resolved by defining
> various directives macros to indicate what behavior is expected,
> with the proviso that compilers would have three options with
> regard to their expansion:
>
> 1. If the directive would imply the compiler's natural behavior,
>    then the compiler may define it as an empty macro.
>
> 2. If the directive would imply an unsupported behavior, then the
>    compiler may define it as something that forces a compilation
>    error.
>
> 3. If the compiler supports multiple behaviors, the compiler may
>    define the directive as an intrinsic that selects a particular
>    behavior.
>
> For example, given the declaration:
>
> struct foo { uint32_t a; uint8_t b; uint16_t b[]; };
>
> there are at least three semantically-sensible combinations of
> sizeof (foo) and __offsetof(foo,b) that I can imagine compiler
> writers coming up with prior to C99:  [6,6], [8,8], and [8,6].  If
> the Standard were to say that preceding the declaration with a
> certain macro would require a particular behavior as follows:
>
>   __STDC_SHORT_FAM_STRUCT would compel the first [offset of FAM is
>   length of struct, but struct size need not be a multiple of
>   struct alignment since it can't be used directly in cases
>   requiring a known-size type]
>
>   __STDC_PADDED_END_FAM_STRUCT would compel the second [structure
>   is padded to its own alignment, and FAM coincides with the end]
>
>   __STDC_INTERNAL_FAM_STRUCT would compel the third [structure is
>   padded to its own alignment, but FAM offset is only padded to
>   satisfy that member's alignment]
>
> then any compiler could legitimately keep on having whichever
> behavior it had started out using as its default, and would not be
> required to do anything new for the new standard except to ignore
> the directive matching its existing behavior and reject programs
> using the other ones, but would also have the option to support
> any additional modes if desired, then there would be no need to
> leave any ambiguity as to what was required for a given piece of
> code.

For some reason you continually confuse the areas of what the
Standard says, what some people believe it says or means, and
what some other people think it ought to say.  As long as that
confusion exists you will be frustrated in your efforts to
have effective discourse about the language.

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

#74993

On Wednesday, November 4, 2015 at 9:48:14 PM UTC-6, Tim Rentsch wrote:
> For some reason you continually confuse the areas of what the
> Standard says, what some people believe it says or means, and
> what some other people think it ought to say.  As long as that
> confusion exists you will be frustrated in your efforts to
> have effective discourse about the language.

I'm sorry I get confused sometimes as to which things I've read over the
years were quoting the actual standard, which were quoting rationales, and
which were quoting other sources that were incorrectly describing what the
Standard said.

That being said, with which of my points do you disagree:

1. Many reasonable programmers have written code that assumes that two
   structures whose perfectly-matched initial sequence is followed by
   arrays that differ only in size will place the arrays at the same
   offsets in the structures, regardless of the sizes thereof.

2. The authors of the C Standard have indicated that they are aware
   of compilers which would place differently sized arrays differently,
   and have never indicated that such placement was forbidden; these
   factors could lead a reasonable person to conclude that the Standard
   allows such placement.

3. The fact that reasonable people misconstrue the meaning of a Standard
   is prima facie evidence of a defect in same.

4. The indicated parts of the C Standard is amenable to two reasonable
   but contradictory readings, of which at most one be correct; thus,
   regardless of which meaning was intended, that part of the Standard is
   defective.

Do you disagree with the points above?

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

#75278

supercat@casperkitty.com writes:

> On Wednesday, November 4, 2015 at 9:48:14 PM UTC-6, Tim Rentsch wrote:
>> For some reason you continually confuse the areas of what the
>> Standard says, what some people believe it says or means, and
>> what some other people think it ought to say.  As long as that
>> confusion exists you will be frustrated in your efforts to
>> have effective discourse about the language.
>
> I'm sorry I get confused sometimes as to which things I've read over
> the years were quoting the actual standard, which were quoting
> rationales, and which were quoting other sources that were
> incorrectly describing what the Standard said.
>
> That being said, with which of my points do you disagree:
>
> 1. Many reasonable programmers have written code that assumes that two
>    structures whose perfectly-matched initial sequence is followed by
>    arrays that differ only in size will place the arrays at the same
>    offsets in the structures, regardless of the sizes thereof.
>
> 2. The authors of the C Standard have indicated that they are aware
>    of compilers which would place differently sized arrays differently,
>    and have never indicated that such placement was forbidden;  these
>    factors could lead a reasonable person to conclude that the Standard
>    allows such placement.
>
> 3. The fact that reasonable people misconstrue the meaning of a Standard
>    is prima facie evidence of a defect in same.
>
> 4. The indicated parts of the C Standard is amenable to two reasonable
>    but contradictory readings, of which at most one be correct;  thus,
>    regardless of which meaning was intended, that part of the Standard is
>    defective.
>
> Do you disagree with the points above?

Let me single out one item:

    The indicated parts of the C Standard is amenable to two
    reasonable but contradictory readings

This is the original question and the point on which all else
hinges.  To me there is no point in looking at the rest until we
have reached a definite conclusion on this question.  I don't
mind listening to any analysis you might offer that helps answer
the question, and offering feedback if anything useful occurs to
me, but I'm not going to try to answer it on my own.

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

#75582

supercat@casperkitty.com wrote:

> On Wednesday, November 4, 2015 at 9:48:14 PM UTC-6, Tim Rentsch wrote:
> > For some reason you continually confuse the areas of what the
> > Standard says, what some people believe it says or means, and
> > what some other people think it ought to say.  As long as that
> > confusion exists you will be frustrated in your efforts to
> > have effective discourse about the language.
> 
> I'm sorry I get confused sometimes as to which things I've read over the
> years were quoting the actual standard, which were quoting rationales, and
> which were quoting other sources that were incorrectly describing what the
> Standard said.

Since the primary sources are, by and large, still available, that's no
excuse.

> That being said, with which of my points do you disagree:
> 
> 1. Many reasonable programmers have written code that assumes that two
>    structures whose perfectly-matched initial sequence is followed by
>    arrays that differ only in size will place the arrays at the same
>    offsets in the structures, regardless of the sizes thereof.

This. It's common, but relying on it is not reasonable unless you 
a) know your code is never going to be ported where it isn't true and 
b) strongly need this assumption.
Particularly point b) is, IYAM, rarely true.

> 3. The fact that reasonable people misconstrue the meaning of a Standard
>    is prima facie evidence of a defect in same.

Assumes "fact" not proven.

Richard

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

#75616

On Tuesday, November 10, 2015 at 9:37:13 AM UTC-6, Richard Bos wrote:
> supercat wrote:
> > 1. Many reasonable programmers have written code that assumes that two
> >    structures whose perfectly-matched initial sequence is followed by
> >    arrays that differ only in size will place the arrays at the same
> >    offsets in the structures, regardless of the sizes thereof.
> 
> This. It's common, but relying on it is not reasonable unless you 
> a) know your code is never going to be ported where it isn't true and 
> b) strongly need this assumption.
> Particularly point b) is, IYAM, rarely true.

I'd suggest that there are a significant number of cases where use of such
types can make code more efficient.  If a compiler doesn't support such
types, is there any portable means to instantiate structures with flexible
array members in storage with static or automatic duration?  Note that
having a struct include a pointer to an array, rather than including the
array in-line, will often make code accessing the array less efficient (one
more level of indirection) and will also mean that memory containing the
data cannot be moved without having to adjust internal pointers).  Note also
that some embedded systems don't support heap storage, and that some systems
have a lot more ROM than RAM (e.g. 64K vs 8k).  Requiring that 10K of font
objects live in ROM rather than RAM because there's no way to have them in
const-static storage is not reasonable.

> > 3. The fact that reasonable people misconstrue the meaning of a Standard
> >    is prima facie evidence of a defect in same.
> 
> Assumes "fact" not proven.

You are asserting that programmers who write code more efficiently than would
otherwise be possible are unreasonable.  Interesting viewpoint.

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

#74119

supercat@casperkitty.com writes:

> On Wednesday, October 28, 2015 at 2:15:29 PM UTC-5, Tim Rentsch wrote:
>> supercat writes:

Just a short followup here.

As we now know that structs with flexible array members are
allowed in unions, that combined with the rule for struct access
(when the struct objects are in a union object), I believe that
approach solves your static initialization problem.  One caveat:
the code should check to make sure the offset of the flexible
array member matches the offset of the corresponding member in
the non-FAM struct.  They should be the same under the Standard's
rules, but you know how those pesky compiler writers are. :)

Given the above, I'm bailing on the effective type stuff
since it seems to be moot now.

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

#74115

Tim Rentsch <txr@alumni.caltech.edu> writes:
> supercat@casperkitty.com writes:
[...]
>> Do any versions of the C Standard allow a structure containing an
>> FAM type to appear within a union?  GCC allows that as an
>> extension, but the C99 compiler I use won't allow that unless gcc
>> extensions are enabled, [snip]
>
> What makes you think C99 (or later) does not allow declaring
> of struct-wth-FAM objects, either as ordinary identfiers or
> as struct/union members?  AFAIK they are allowed.  When I tried
> compiling a simple test case with gcc, using -std=c99 -pedantic,
> no diagnostics were given.  So I'm at a loss to understand your
> question here.

The restriction isn't in the same paragraph that discusses flexible
array members, so it's easy to miss.

N1570 6.7.2.1p18 describes flexible array members.   Paragraph 3 of the
same section says:

    A structure or union shall not contain a member with incomplete
    or function type (hence, a structure shall not contain an
    instance of itself, but may contain a pointer to an instance of
    itself), except that the last member of a structure with more
    than one named member may have incomplete array type; such
    a structure (and any union containing, possibly recursively,
    a member that is such a structure) shall not be a member of a
    structure or an element of an array.

Annoyingly, that paragraph doesn't use the phrase "flexible array
member".

So the answer to supercat's question is no: neither C99 nor C11 permits
an FAM as a member of a structure or as an element of an array.  It
does, however, permit a FAM as a member of a union.  (Tim, perhaps your
test case used a FAM as a union member?)

This translation unit:

    struct foo { int len; unsigned char fam[]; };
    struct bar { struct foo nope; };

violates a constraint (but gcc accepts it if extensions are enabled).
This one:

    struct foo { int len; unsigned char fam[]; };
    union  bar { struct foo nope; };

does not violate any constraint in C99 or C11.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#74118

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> supercat@casperkitty.com writes:
>
> [...]
>
>>> Do any versions of the C Standard allow a structure containing an
>>> FAM type to appear within a union?  GCC allows that as an
>>> extension, but the C99 compiler I use won't allow that unless gcc
>>> extensions are enabled, [snip]
>>
>> What makes you think C99 (or later) does not allow declaring
>> of struct-wth-FAM objects, either as ordinary identfiers or
>> as struct/union members?  AFAIK they are allowed.  When I tried
>> compiling a simple test case with gcc, using -std=c99 -pedantic,
>> no diagnostics were given.  So I'm at a loss to understand your
>> question here.
>
> The restriction isn't in the same paragraph that discusses flexible
> array members, so it's easy to miss.  [snip elaboration]

Your comments are right on the money.  Thank you
for the help.

[toc] | [prev] | [standalone]

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

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

csiph-web