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

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

Padding involved

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

Contents

  Padding involved anish singh <anish198519851985@gmail.com> - 2014-03-07 13:13 -0800
    Re: Padding involved jacob navia <jacob@spamsink.net> - 2014-03-07 22:17 +0100
    Re: Padding involved Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-07 16:26 -0500
      Re: Padding involved anish singh <anish198519851985@gmail.com> - 2014-03-07 13:49 -0800
        Re: Padding involved Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-07 18:11 -0500
          Re: Padding involved anish kumar <yesanishhere@gmail.com> - 2014-03-07 15:19 -0800
            Re: Padding involved Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2014-03-07 16:26 -0700
              Re: Padding involved anish kumar <yesanishhere@gmail.com> - 2014-03-07 15:41 -0800
                Re: Padding involved James Kuyper <jameskuyper@verizon.net> - 2014-03-07 18:50 -0500
              Re: Padding involved glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-08 00:10 +0000
                Re: Padding involved Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2014-03-08 09:27 -0700
            Re: Padding involved Keith Thompson <kst-u@mib.org> - 2014-03-07 16:24 -0800
              Re: Padding involved anish kumar <yesanishhere@gmail.com> - 2014-03-07 16:45 -0800
                Re: Padding involved Kaz Kylheku <kaz@kylheku.com> - 2014-03-08 01:03 +0000
                  Re: Padding involved David Thompson <dave.thompson2@verizon.net> - 2014-03-28 06:11 -0400
                    Re: Padding involved glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-28 18:45 +0000
                      Re: Padding involved James Kuyper <jameskuyper@verizon.net> - 2014-03-28 15:23 -0400
                        Re: Padding involved Keith Thompson <kst-u@mib.org> - 2014-03-28 12:40 -0700
                        Re: Padding involved glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-28 21:19 +0000
                          Re: Padding involved Stephen Sprunk <stephen@sprunk.org> - 2014-03-28 17:07 -0500
                            Re: Padding involved Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-28 18:25 -0400
                              Re: Padding involved Stephen Sprunk <stephen@sprunk.org> - 2014-03-28 21:15 -0500
                                Re: Padding involved Keith Thompson <kst-u@mib.org> - 2014-03-29 01:03 -0700
                                  Re: Padding involved Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 14:23 -0700
                                    Re: Padding involved glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-30 01:43 +0000
                            Re: Padding involved James Kuyper <jameskuyper@verizon.net> - 2014-03-28 21:32 -0400
                              Re: Padding involved Richard Damon <Richard@Damon-Family.org> - 2014-03-28 21:59 -0400
                              Re: Padding involved Stephen Sprunk <stephen@sprunk.org> - 2014-03-29 00:46 -0500
                                Re: Padding involved James Kuyper <jameskuyper@verizon.net> - 2014-03-29 08:51 -0400
                                  Re: Padding involved Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-29 08:57 -0400
                                    Re: Padding involved Stephen Sprunk <stephen@sprunk.org> - 2014-03-30 18:53 -0500
                                      Re: Padding involved Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-30 20:25 -0400
                                        Re: Padding involved Stephen Sprunk <stephen@sprunk.org> - 2014-03-31 11:34 -0500
                                          Re: Padding involved Keith Thompson <kst-u@mib.org> - 2014-03-31 11:27 -0700
                                            Re: Padding involved Keith Thompson <kst-u@mib.org> - 2014-03-31 11:36 -0700
                                              Re: Padding involved Kaz Kylheku <kaz@kylheku.com> - 2014-03-31 19:14 +0000
                                                Re: Padding involved Stephen Sprunk <stephen@sprunk.org> - 2014-03-31 15:43 -0500
                                                  Re: Padding involved Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-04-01 03:12 +0300
                                                    Re: Padding involved Stephen Sprunk <stephen@sprunk.org> - 2014-04-03 00:45 -0500
                                  Re: Padding involved Stephen Sprunk <stephen@sprunk.org> - 2014-03-29 13:02 -0500
                                    Re: Padding involved Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-29 14:44 -0400
                                    Re: Padding involved glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-29 19:49 +0000
                                    Re: Padding involved James Kuyper <jameskuyper@verizon.net> - 2014-03-30 19:12 -0400
                                      Re: Padding involved Stephen Sprunk <stephen@sprunk.org> - 2014-03-31 16:20 -0500
                                        Re: Padding involved James Kuyper <jameskuyper@verizon.net> - 2014-03-31 17:53 -0400
                                          Re: Padding involved Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-04-01 03:22 +0300
                                          Re: Padding involved Stephen Sprunk <stephen@sprunk.org> - 2014-04-04 14:36 -0500
                                            Re: Padding involved James Kuyper <jameskuyper@verizon.net> - 2014-04-04 17:33 -0400
                                            Re: Padding involved Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-14 13:46 -0700
                                              Re: Padding involved glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-14 22:00 +0000
                                                Re: Padding involved Keith Thompson <kst-u@mib.org> - 2014-04-14 15:37 -0700
                                            Re: Padding involved Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-17 09:11 -0700
                                      Re: Padding involved Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-14 13:25 -0700
                              Re: Padding involved Keith Thompson <kst-u@mib.org> - 2014-03-29 00:57 -0700
                                Re: Padding involved James Kuyper <jameskuyper@verizon.net> - 2014-03-29 08:57 -0400
                                  Re: Padding involved Keith Thompson <kst-u@mib.org> - 2014-03-29 14:18 -0700
                                    Re: Padding involved Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-30 12:02 -0700
                                      Re: Padding involved Keith Thompson <kst-u@mib.org> - 2014-03-30 19:35 -0700
                                        Re: Padding involved Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-14 12:54 -0700
                                  Re: Padding involved Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 14:44 -0700
                            Re: Padding involved glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-29 03:50 +0000
                              Re: Padding involved James Kuyper <jameskuyper@verizon.net> - 2014-03-29 09:02 -0400
                              Re: Padding involved Stephen Sprunk <stephen@sprunk.org> - 2014-03-29 13:19 -0500
                          Re: Padding involved James Kuyper <jameskuyper@verizon.net> - 2014-03-28 21:21 -0400
                      Re: Padding involved Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-28 15:27 -0400
                      Re: Padding involved Kaz Kylheku <kaz@kylheku.com> - 2014-03-28 19:54 +0000
                      Re: Padding involved Stephen Sprunk <stephen@sprunk.org> - 2014-03-28 15:02 -0500
            Re: Padding involved Kaz Kylheku <kaz@kylheku.com> - 2014-03-08 00:43 +0000
            Re: Padding involved Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-07 20:20 -0500
      Re: Padding involved anish singh <anish198519851985@gmail.com> - 2014-03-07 13:49 -0800
    Re: Padding involved James Kuyper <jameskuyper@verizon.net> - 2014-03-07 16:46 -0500
    Re: Padding involved "BartC" <bc@freeuk.com> - 2014-03-07 21:59 +0000
      Re: Padding involved anish kumar <yesanishhere@gmail.com> - 2014-03-07 14:34 -0800
        Re: Padding involved "BartC" <bc@freeuk.com> - 2014-03-07 23:59 +0000
      Re: Padding involved Keith Thompson <kst-u@mib.org> - 2014-03-07 15:15 -0800
        Re: Padding involved "BartC" <bc@freeuk.com> - 2014-03-08 10:08 +0000
          Re: Padding involved Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-08 12:39 +0000
          Re: Padding involved Keith Thompson <kst-u@mib.org> - 2014-03-08 14:03 -0800
    Re: Padding involved Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-03-08 09:01 -0800

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#42300

On 3/29/2014 2:02 PM, Stephen Sprunk wrote:
> On 29-Mar-14 07:51, James Kuyper wrote:
>>[...]
>> It seems to me that this cannot be correct. It is permitted for a
>> struct to have stricter alignment than it's member's types, but not
>> for it to be less strict.
>
> So, compiler bug?

     No, typo.  Go upthread and look carefully at the code.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

#42305

Stephen Sprunk <stephen@sprunk.org> wrote:

(snip, someone wrote)
>>> % ./a.out
>>> alignof(double) = 8
>>> alignof(double[2]) = 8 
>>> alignof(double complex) = 8
>>> alignof(struct twodouble) = 4
>>> % gcc -v 
>>> Using built-in specs.
>>> Target: i486-linux-gnu
 
>>> The first three are what I expected, but the last one has me quite 
>>> confused; how can a struct have less strict alignment than its
>>> members?
 
>> It seems to me that this cannot be correct. It is permitted for a
>> struct to have stricter alignment than it's member's types, but not
>> for it to be less strict.
 
> So, compiler bug?
 
> It seems obvious that, for array indexing to work, a struct's alignment
> must be at least as strict as any of its members, but I can't find the
> specific text in N1570 that says so.

Since x86 (I presume that is what this is) doesn't require any
alignment, it isn't so obvious that it is wrong. It does seem
unusual, though.

-- glen

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

#42367

On 03/29/2014 02:02 PM, Stephen Sprunk wrote:
...
> It's not even permitted.  As Keith cited, according to N1570 6.5.3.4p3,
>  _Alignof(double[2]) == _Alignof(double).

I've acknowledged that I missed that clause. The restriction it imposes
is new in C2011, even thought it could have been expressed in different
terms in previous versions of the standard.

>> Perhaps the implementors didn't consider the increased speed of the 
>> instructions he was talking about to be a sufficiently important
>> issue.
> 
> There's nothing stopping the implementation from _delivering_ stricter
> alignment than promised in order to make use of such instructions, but
> there doesn't seem to be any way for it to promise to do so.

Alignment requirements are implementation-defined, which means that a
conforming implementation of C must come with documentation that
describes them. Prior to C2011, that documentation could have specified
that double[N] will have 16 byte alignment whenever N is even. Keith
postulates to the contrary, but I don't think it can easily be proven.

>>> % ./a.out
>>> alignof(double) = 8
>>> alignof(double[2]) = 8 
>>> alignof(double complex) = 8
>>> alignof(struct twodouble) = 4
>>> % gcc -v 
>>> Using built-in specs.
>>> Target: i486-linux-gnu
>>> ...
>>>
>>> The first three are what I expected, but the last one has me quite 
>>> confused; how can a struct have less strict alignment than its
>>> members?
>>
>> It seems to me that this cannot be correct. It is permitted for a
>> struct to have stricter alignment than it's member's types, but not
>> for it to be less strict.
> 
> So, compiler bug?

It's been pointed out that the code provided says alignof(struct
twdouble). Since no struct with that name has been defined, it's an
incomplete type. I'm not sure what the specification of GNU C's
__alignof__() is, but I'm surprised that giving it an incomplete type
didn't result in an error message. I doubt that there's anything that
can be usefully guaranteed about it's result.

> It seems obvious that, for array indexing to work, a struct's alignment
> must be at least as strict as any of its members, but I can't find the
> specific text in N1570 that says so.

There is no text that says so directly. It's something that can be
derived from what the standard says about arrays, the offsetof() macro
(which implies that the offset is a constant depending only upon the
struct definition, rather than being dependent upon which instance of
the struct is being referred to), and alignment requirements.
-- 
James Kuyper

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

#42419

On 30-Mar-14 18:12, James Kuyper wrote:
> On 03/29/2014 02:02 PM, Stephen Sprunk wrote:
>> It's not even permitted.  As Keith cited, according to N1570 6.5.3.4p3,
>> _Alignof(double[2]) == _Alignof(double).
> 
> I've acknowledged that I missed that clause. The restriction it imposes
> is new in C2011, even thought it could have been expressed in different
> terms in previous versions of the standard.

AIUI, such additions appear because that was the intent (or at least
known practice) all along but someone discovered it wasn't actually
stated and asked for clarification.

>> There's nothing stopping the implementation from _delivering_ stricter
>> alignment than promised in order to make use of such instructions, but
>> there doesn't seem to be any way for it to promise to do so.
> 
> Alignment requirements are implementation-defined, which means that a
> conforming implementation of C must come with documentation that
> describes them. Prior to C2011, that documentation could have specified
> that double[N] will have 16 byte alignment whenever N is even. Keith
> postulates to the contrary, but I don't think it can easily be proven.

I wouldn't expect array dimension to affect alignment, and IMHO most
people would assume an object would have the same alignment as an array
of one object (and vice versa).  It seems worth saying so explicitly,
though, based on the debate here.

>> It seems obvious that, for array indexing to work, a struct's alignment
>> must be at least as strict as any of its members, but I can't find the
>> specific text in N1570 that says so.
> 
> There is no text that says so directly. It's something that can be
> derived from what the standard says about arrays, the offsetof() macro
> (which implies that the offset is a constant depending only upon the
> struct definition, rather than being dependent upon which instance of
> the struct is being referred to), and alignment requirements.

That seems sufficient, but wouldn't it be simpler for them to just say
so explicitly if that was the intent?

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#42421

On 03/31/2014 05:20 PM, Stephen Sprunk wrote:
> On 30-Mar-14 18:12, James Kuyper wrote:
>> On 03/29/2014 02:02 PM, Stephen Sprunk wrote:
...
>>> It seems obvious that, for array indexing to work, a struct's alignment
>>> must be at least as strict as any of its members, but I can't find the
>>> specific text in N1570 that says so.
>>
>> There is no text that says so directly. It's something that can be
>> derived from what the standard says about arrays, the offsetof() macro
>> (which implies that the offset is a constant depending only upon the
>> struct definition, rather than being dependent upon which instance of
>> the struct is being referred to), and alignment requirements.
> 
> That seems sufficient, but wouldn't it be simpler for them to just say
> so explicitly if that was the intent?

Yes, and I wouldn't object to adding such text, at least as a footnote.

However, realize that there's a wide variety of other interesting
mathematical results that can be derived from those same facts. For
instance, in C2011, the requirement was added that alignment
requirements had to be powers of 2, which matches what essentially all
known implementations of C actually do, or have ever actually done.
However, prior to that change, a conforming implementation could have
had alignment requirements for short and long that were 3 bytes and 5
bytes, respectively. From C99, it could be proven, using the same set of
facts mentioned above, that any struct or union containing both a short
and a long must have a alignment requirement when using that
implementation, which is an integer multiple of both 3 and 5, and
therefore must be a multiple of 15.

Should the C99 standard have explicitly said something that would lead
to that conclusion more directly, perhaps by expressing the relationship
in terms of LCM (least common multiple)? I know from personal experience
that very few people were aware of that fact.  More than a few people
argued with me about this when I brought it up. I think this was mainly
because most of them had the "power of 2" rule already engraved in their
brains, long before it was officially adopted as a requirement. When a
and b are non-negative integer powers of two, LCM(a,b) == MAX(a,b),
which is what most people actually used when thinking about such issues.

How do you decide which technically redundant facts need to be
explicitly spelled out, and which ones should be left for readers to
derive for themselves?

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

#42435

James Kuyper <jameskuyper@verizon.net> writes:
> On 03/31/2014 05:20 PM, Stephen Sprunk wrote:
> > On 30-Mar-14 18:12, James Kuyper wrote:
> >> On 03/29/2014 02:02 PM, Stephen Sprunk wrote:
> ...
> >>> It seems obvious that, for array indexing to work, a struct's alignment
> >>> must be at least as strict as any of its members, but I can't find the
> >>> specific text in N1570 that says so.
> >>
> >> There is no text that says so directly. It's something that can be
> >> derived from what the standard says about arrays, the offsetof() macro
> >> (which implies that the offset is a constant depending only upon the
> >> struct definition, rather than being dependent upon which instance of
> >> the struct is being referred to), and alignment requirements.
> > 
> > That seems sufficient, but wouldn't it be simpler for them to just say
> > so explicitly if that was the intent?
> 
> Yes, and I wouldn't object to adding such text, at least as a footnote.
> 
> However, realize that there's a wide variety of other interesting
> mathematical results that can be derived from those same facts. For
> instance, in C2011, the requirement was added that alignment
> requirements had to be powers of 2, which matches what essentially all
> known implementations of C actually do, or have ever actually done.

Don't say that - there are probably corners of N-bit la-la-land 
(for N itself not a power of 2) for which it hasn't always held!
I can't remember what some old 24-bit DSPs did when they were
compiled to pack strings (3 chars per word), as the whole concept
of doing dodgy stuff that required knowledge of alignment was so
taboo that nobody ever seemed to do it. You were either dealing 
with words, or you were dealing with packed strings, there was
never a sane context where you'd need to deal with either.

> How do you decide which technically redundant facts need to be
> explicitly spelled out, and which ones should be left for readers to
> derive for themselves?

I'd say this can be derived from basic principles, as it
seems rather obvious (including the LCM aspect you mention,
but my background is pure mathematics).

Phil
-- 
Religion is too important a matter to its devotees to be a subject of 
ridicule. If they indulge in absurdities, they are to be pitied rather
than ridiculed. -- Immanuel Kant (1724-1804), lecture at Konigsberg, 1775

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

#42581

On 31-Mar-14 16:53, James Kuyper wrote:
> On 03/31/2014 05:20 PM, Stephen Sprunk wrote:
>> On 30-Mar-14 18:12, James Kuyper wrote:
>>> On 03/29/2014 02:02 PM, Stephen Sprunk wrote:
>>>> It seems obvious that, for array indexing to work, a struct's
>>>> alignment must be at least as strict as any of its members, but
>>>> I can't find the specific text in N1570 that says so.
>>> 
>>> There is no text that says so directly. It's something that can
>>> be derived from what the standard says about arrays, the
>>> offsetof() macro (which implies that the offset is a constant
>>> depending only upon the struct definition, rather than being
>>> dependent upon which instance of the struct is being referred
>>> to), and alignment requirements.
>> 
>> That seems sufficient, but wouldn't it be simpler for them to just
>> say so explicitly if that was the intent?
> 
> Yes, and I wouldn't object to adding such text, at least as a
> footnote.
> 
> However, realize that there's a wide variety of other interesting 
> mathematical results that can be derived from those same facts. For 
> instance, in C2011, the requirement was added that alignment 
> requirements had to be powers of 2, which matches what essentially
> all known implementations of C actually do, or have ever actually
> done. However, prior to that change, a conforming implementation
> could have had alignment requirements for short and long that were 3
> bytes and 5 bytes, respectively. From C99, it could be proven, using
> the same set of facts mentioned above, that any struct or union
> containing both a short and a long must have a alignment requirement
> when using that implementation, which is an integer multiple of both
> 3 and 5, and therefore must be a multiple of 15.

Could one have addressed that by stating the struct's alignment must be
a positive integer multiple of each* member's alignment?

(* Or should that be "every"?  Neither sounds exactly correct.)

Once you require power-of-two alignments, though, it suffices to say
that the struct's alignment must be at least as strict as all of its
members.

> Should the C99 standard have explicitly said something that would
> lead to that conclusion more directly, perhaps by expressing the
> relationship in terms of LCM (least common multiple)? I know from
> personal experience that very few people were aware of that fact.
> More than a few people argued with me about this when I brought it
> up. I think this was mainly because most of them had the "power of 2"
> rule already engraved in their brains, long before it was officially
> adopted as a requirement. When a and b are non-negative integer
> powers of two, LCM(a,b) == MAX(a,b), which is what most people
> actually used when thinking about such issues.

Good point, though the argument for LCM would be clearer if your example
alignments weren't relatively prime, i.e. if GCF(a,b) != 1.

Now, of course, LCM(a,b) == MAX(a,b) and GCF(a,b) == MIN(a,b).

> How do you decide which technically redundant facts need to be 
> explicitly spelled out, and which ones should be left for readers to 
> derive for themselves?

I suppose that's a judgment call, but I found it surprising that when
searching N1570 for "alignment" and then "struct", I found absolutely
nothing useful about how structs needed to be aligned.  That seems to
indicate they erred on the side of not enough redundancy, but I can
appreciate that redundancy introduces a risk of inconsistency.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#42588

On 04/04/2014 03:36 PM, Stephen Sprunk wrote:
> On 31-Mar-14 16:53, James Kuyper wrote:
...
>> However, realize that there's a wide variety of other interesting 
>> mathematical results that can be derived from those same facts. For 
>> instance, in C2011, the requirement was added that alignment 
>> requirements had to be powers of 2, which matches what essentially
>> all known implementations of C actually do, or have ever actually
>> done. However, prior to that change, a conforming implementation
>> could have had alignment requirements for short and long that were 3
>> bytes and 5 bytes, respectively. From C99, it could be proven, using
>> the same set of facts mentioned above, that any struct or union
>> containing both a short and a long must have a alignment requirement
>> when using that implementation, which is an integer multiple of both
>> 3 and 5, and therefore must be a multiple of 15.
> 
> Could one have addressed that by stating the struct's alignment must be
> a positive integer multiple of each* member's alignment?
> 
> (* Or should that be "every"?  Neither sounds exactly correct.)

I think "every" would be correct.

> Once you require power-of-two alignments, though, it suffices to say
> that the struct's alignment must be at least as strict as all of its
> members.

Which is why I had to hark back to an earlier version of the standard to
come up with an example of something that is less obvious.

>> Should the C99 standard have explicitly said something that would
>> lead to that conclusion more directly, perhaps by expressing the
>> relationship in terms of LCM (least common multiple)? I know from
>> personal experience that very few people were aware of that fact.
>> More than a few people argued with me about this when I brought it
>> up. I think this was mainly because most of them had the "power of 2"
>> rule already engraved in their brains, long before it was officially
>> adopted as a requirement. When a and b are non-negative integer
>> powers of two, LCM(a,b) == MAX(a,b), which is what most people
>> actually used when thinking about such issues.
> 
> Good point, though the argument for LCM would be clearer if your example
> alignments weren't relatively prime, i.e. if GCF(a,b) != 1.

I suppose it would be clearer what the general rule is if a and b have
some factors in common, and each one has some factors not in common with
the other; such as 4 and 6, with an LCM of 12.

> Now, of course, LCM(a,b) == MAX(a,b) and GCF(a,b) == MIN(a,b).
> 
>> How do you decide which technically redundant facts need to be 
>> explicitly spelled out, and which ones should be left for readers to 
>> derive for themselves?
> 
> I suppose that's a judgment call, but I found it surprising that when
> searching N1570 for "alignment" and then "struct", I found absolutely
> nothing useful about how structs needed to be aligned.  That seems to
> indicate they erred on the side of not enough redundancy, but I can
> appreciate that redundancy introduces a risk of inconsistency.

In standardese, that's handled by distinguishing between normative and
non-normative text. The normative text should never say the same thing
two different ways, because of the potential problems if the two ways
turn out to be subtly in conflict with each other. However, you can put
redundant statements in non-normative text, such as footnotes, and if
they turn out to conflict with the normative text, the normative text is
right, and the non-normative text is not. The accuracy of the standard
itself isn't in danger, just that of the individual footnotes.

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

#42913

Stephen Sprunk <stephen@sprunk.org> writes:

>> [concerning the relationship of alignment of a struct type
>>  and alignment of the types of members of the struct]
>
> Could one have addressed that by stating the struct's alignment
> must be a positive integer multiple of each* member's alignment?
>
> (* Or should that be "every"?  Neither sounds exactly correct.)

Here "each" is better.  The reason is the alignments in the
different cases are not the same but depend on the member.
Compare, for example,

    "Every student worked on the class project."

and

    "The professor will grade the homeworks of each student."

In the first case we say "every student" because they were all
working as a group.  But in the second case it would be wrong to
say "the homeworks of every student" because students do homework
by themselves, not as a group, and are graded individually.
Similarly the alignment of a struct will be a positive integer
multiple of the alignment of each member - not the same alignment,
or the same multiple, but in each case the one will be some
multiple of the other.  There isn't a single alignment for every
member, only for each member.

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

#42917

Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Stephen Sprunk <stephen@sprunk.org> writes:
(snip)
>> (* Or should that be "every"?  Neither sounds exactly correct.)
 
> Here "each" is better.  The reason is the alignments in the
> different cases are not the same but depend on the member.
> Compare, for example,
 
>    "Every student worked on the class project."
 
> and
 
>    "The professor will grade the homeworks of each student."
 
> In the first case we say "every student" because they were all
> working as a group.  

But "every" also implies that no-one was left out, such as being
sick on those days. 

> But in the second case it would be wrong to
> say "the homeworks of every student" because students do homework
> by themselves, not as a group, and are graded individually.

In this case, it doesn't imply that the professor graded "every"
student, maybe the TA graded some of them. 

But even more, I have known professors that graded mulitple student
projects as a group, such that everyone got the same grade.

In one case I know (CS138) it was intended to force students
to work together cooperatively.  As many projects depend on the
contribution of all members, especially programming projects,
it makes some sense.

> Similarly the alignment of a struct will be a positive integer
> multiple of the alignment of each member - not the same alignment,
> or the same multiple, but in each case the one will be some
> multiple of the other.  There isn't a single alignment for every
> member, only for each member.

-- glen

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

#42922

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Stephen Sprunk <stephen@sprunk.org> writes:
> (snip)
>>> (* Or should that be "every"?  Neither sounds exactly correct.)
>  
>> Here "each" is better.  The reason is the alignments in the
>> different cases are not the same but depend on the member.
>> Compare, for example,
>  
>>    "Every student worked on the class project."
>  
>> and
>  
>>    "The professor will grade the homeworks of each student."
>  
>> In the first case we say "every student" because they were all
>> working as a group.  
>
> But "every" also implies that no-one was left out, such as being
> sick on those days. 

This is a minor point, and getting off-topic, but ...

> Could one have addressed that by stating the struct's alignment
> must be a positive integer multiple of each* member's alignment?
>
> (* Or should that be "every"?  Neither sounds exactly correct.)

The phrase "every member's alignment" could imply that the members,
as a group, have an alignment that they share.  The phrase "each
member's alignment" more clearly implies that each member has its
own individual alignment, and that the struct's alignment is a
positive integer multiple of the first member's alignment *and*
of the second member's alignment *and* ....

It's not a very strong implication either way, and it would take a
perverse reading to interpret "every" in the way I suggested, but
I find "each" clearer and more precise than "every" in this context.

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

#43044

Stephen Sprunk <stephen@sprunk.org> writes:

>> [concerning the relationship of alignment of a struct type
>>  and alignment of the types of members of the struct]
>
> Could one have addressed that by stating the struct's alignment
> must be a positive integer multiple of each* member's alignment?
>
> (* Or should that be "every"?  Neither sounds exactly correct.)

I almost forgot - the alignment of a struct is some positive
integer multiple of each non-bit-field member's alignment.

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

#42912

James Kuyper <jameskuyper@verizon.net> writes:

> On 03/29/2014 02:02 PM, Stephen Sprunk wrote:
> ...
>> It's not even permitted.  As Keith cited, according to N1570 6.5.3.4p3,
>>  _Alignof(double[2]) == _Alignof(double).
>
> I've acknowledged that I missed that clause.  The restriction it
> imposes is new in C2011, even thought it could have been expressed
> in different terms in previous versions of the standard.
>
>>> Perhaps the implementors didn't consider the increased speed of
>>> the instructions he was talking about to be a sufficiently
>>> important issue.
>> 
>> There's nothing stopping the implementation from _delivering_
>> stricter alignment than promised in order to make use of such
>> instructions, but there doesn't seem to be any way for it to
>> promise to do so.
>
> Alignment requirements are implementation-defined, [snip
> elaboration]

This isn't exactly right.  The alignments of non-bit-field struct
members are implementation-defined, and the results of _Alignof
in C11 are implementation-defined, but the alignments of types
are not, and have never been, implementation-defined.  Indeed if
the alignment of types were implementation-defined, there would
be no reason for the Stadard to say that the results of _Alignof
are implementation-defined, which it does in 6.5.3.4 p5.

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

#42275

James Kuyper <jameskuyper@verizon.net> writes:
> On 03/28/2014 06:07 PM, Stephen Sprunk wrote:
>> On 28-Mar-14 16:19, glen herrmannsfeldt wrote:
>>> James Kuyper <jameskuyper@verizon.net> wrote:
> ...
>>>> On the platform you describe, must every double be aligned on a 16
>>>> byte address, so the SSE instructions can always be used?
>>>
>>> Pairs of doubles are aligned on 16 byte boundaries.
>> 
>> Standard C has no type "pair of doubles".
>
> Actually, that's precisely what double[2] is; and _Alignof(double[2])
> probably would be 16 on such a platform.

N1570 6.5.3.4p3:

    The _Alignof operator yields the alignment requirement of its
    operand type. The operand is not evaluated and the result is
    an integer constant. When applied to an array type, the result
    is the alignment requirement of the element type.

So _Alignof(double[2]) == _Alignof(double), by definition.

[...]

> While that's the only guarantee, an implementation is free to impose
> stricter alignment requirements on arrays of a type than on the type itself.

It's not free to *require* a stricter alignment.  Given:

    double arr[3];

both arr[0] and arr[1] can be treated as the first element of a
double[2] object.  (I'm *fairly* sure of that, but I don't have a
citation to prove it.)

Of course a compiler can allocate arrays at stricter alignments than
required, but it must still be able to (generate code to) access them at
the alignment of their element type.

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

#42282

On 03/29/2014 03:57 AM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
...
>> Actually, that's precisely what double[2] is; and _Alignof(double[2])
>> probably would be 16 on such a platform.
> 
> N1570 6.5.3.4p3:
> 
>     The _Alignof operator yields the alignment requirement of its
>     operand type. The operand is not evaluated and the result is
>     an integer constant. When applied to an array type, the result
>     is the alignment requirement of the element type.

Ah - that's new, I think - I haven't had time to fully digest the
changes made in C2011. In principle the same requirement could have been
worded in earlier versions of the standard in terms of the alignment of
the type without mentioning _Alignof(), but I don't think that it was.
Am I correct?
-- 
James Kuyper

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

#42316

James Kuyper <jameskuyper@verizon.net> writes:
> On 03/29/2014 03:57 AM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
> ...
>>> Actually, that's precisely what double[2] is; and _Alignof(double[2])
>>> probably would be 16 on such a platform.
>> 
>> N1570 6.5.3.4p3:
>> 
>>     The _Alignof operator yields the alignment requirement of its
>>     operand type. The operand is not evaluated and the result is
>>     an integer constant. When applied to an array type, the result
>>     is the alignment requirement of the element type.
>
> Ah - that's new, I think - I haven't had time to fully digest the
> changes made in C2011. In principle the same requirement could have been
> worded in earlier versions of the standard in terms of the alignment of
> the type without mentioning _Alignof(), but I don't think that it was.
> Am I correct?

Search for every occurrence of "alignment" in N1256, I see no explicit
statement about the alignment of array types (which is a bit
surprising).

But I think the *required* alignment for an array type was already the
same as the required alignment for the element type.

For example, I *think* this program, which treats "slices" of a
double[3] array as double[2] arrays, is strictly conforming in
both C99 and C11.  If double[2] could have a stricter alignment
requirement than double, its behavior would be undefined under any
implementation that imposes such an alignment.

#include <stdio.h>

typedef double pair[2];

static void print(pair *p) {
    printf("%g %g\n", (*p)[0], (*p)[1]);
}

int main(void) {
    double arr[3] = { 10.0, 20.0, 30.0 };
    pair *p0 = (pair*)&arr[0];
    pair *p1 = (pair*)&arr[1];
    print(p0);
    print(p1);
}

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

#42361

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

> James Kuyper <jameskuyper@verizon.net> writes:
>> On 03/29/2014 03:57 AM, Keith Thompson wrote:
>>> James Kuyper <jameskuyper@verizon.net> writes:
>> ...
>>>> Actually, that's precisely what double[2] is; and
>>>> _Alignof(double[2]) probably would be 16 on such a platform.
>>> 
>>> N1570 6.5.3.4p3:
>>> 
>>>     The _Alignof operator yields the alignment requirement of its
>>>     operand type. The operand is not evaluated and the result is
>>>     an integer constant. When applied to an array type, the result
>>>     is the alignment requirement of the element type.
>>
>> Ah - that's new, I think - I haven't had time to fully digest the
>> changes made in C2011. In principle the same requirement could have
>> been worded in earlier versions of the standard in terms of the
>> alignment of the type without mentioning _Alignof(), but I don't
>> think that it was.  Am I correct?
>
> Search for every occurrence of "alignment" in N1256, I see no
> explicit statement about the alignment of array types (which is a
> bit surprising).
>
> But I think the *required* alignment for an array type was already
> the same as the required alignment for the element type.
>
> For example, I *think* this program, which treats "slices" of a
> double[3] array as double[2] arrays, is strictly conforming in
> both C99 and C11.  If double[2] could have a stricter alignment
> requirement than double, its behavior would be undefined under any
> implementation that imposes such an alignment.
>
> #include <stdio.h>
>
> typedef double pair[2];
>
> static void print(pair *p) {
>     printf("%g %g\n", (*p)[0], (*p)[1]);
> }
>
> int main(void) {
>     double arr[3] = { 10.0, 20.0, 30.0 };
>     pair *p0 = (pair*)&arr[0];
>     pair *p1 = (pair*)&arr[1];
>     print(p0);
>     print(p1);
> }

If you mean the example program as part of an argument, it's
a circular argument.  The program is strictly conforming if
and only if the alignment of double[2] must be the same as
the alignment of double.  Saying the given program is strictly
conforming is just a sneaky way of begging the question.

I partly agree with your comment re alignment in C99/N1256, in the
sense that apparently there is an /expectation/ that alignment of
arrays must match the alignment of their elements.  However, I
don't find any statement, or combination of statements, in
C99/N1256 that either requires or logically implies that such a
limitation must hold.  This omission means some code that looks
reasonable might have undefined behavior.  Consider for example
the following code fragment, accepted under C99 (and also C90):

    int a23[2][3];
    int a32[3][2];
    int (*a)[];
    int (*b)[2] = a32;
    int (*c)[3] = a23;
    a = a23;
    b = a;
    a = a32;
    c = a;

Does this code have undefined behavior or not?  In particular, are
the assignments to b and c okay, which wouldn't be allowed without
using 'a' as an intermediary?  AFAICS the Standard doesn't require
the alignments of the types (int[2]) and (int[3]) to be the same.
(To simplify the discussion let's assume the alignment of (int[])
is the same as that of (int) - this doesn't change the question in
any significant way.)  If indeed it is the case that the Standard
does not either require or logically imply that the alignments of
these two types must be the same, then an implementation is free
to make them different, which means the program has undefined
behavior.  Furthermore such a possibility isn't that farfetched.
If we add a few lines

    b[2][1] = 0;
    c[1][2] = 0;

we still have acceptable standard C code (ie, does not require a
diagnostic), yet it certainly crosses into undefined behavior.
If we take the Standard at its word, then the alignments of the
types involved here are not constrained to have the same value,
and when they are different the semantics of pointer conversion
explicitly deems such conversions undefined behavior.

Let me say again that I think the Standard was written with the
expectation, and also is read by most people as meaning to imply,
that the alignment of array types will be the same as that of
their elements.  However I don't find any text, either normative
or informative, in the Standard itself (ie, pre-C11) that supports
this supposition.

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

#42377

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> On 03/29/2014 03:57 AM, Keith Thompson wrote:
>>>> James Kuyper <jameskuyper@verizon.net> writes:
>>> ...
>>>>> Actually, that's precisely what double[2] is; and
>>>>> _Alignof(double[2]) probably would be 16 on such a platform.
>>>> 
>>>> N1570 6.5.3.4p3:
>>>> 
>>>>     The _Alignof operator yields the alignment requirement of its
>>>>     operand type. The operand is not evaluated and the result is
>>>>     an integer constant. When applied to an array type, the result
>>>>     is the alignment requirement of the element type.
>>>
>>> Ah - that's new, I think - I haven't had time to fully digest the
>>> changes made in C2011. In principle the same requirement could have
>>> been worded in earlier versions of the standard in terms of the
>>> alignment of the type without mentioning _Alignof(), but I don't
>>> think that it was.  Am I correct?
>>
>> Search for every occurrence of "alignment" in N1256, I see no
>> explicit statement about the alignment of array types (which is a
>> bit surprising).
>>
>> But I think the *required* alignment for an array type was already
>> the same as the required alignment for the element type.
>>
>> For example, I *think* this program, which treats "slices" of a
>> double[3] array as double[2] arrays, is strictly conforming in
>> both C99 and C11.  If double[2] could have a stricter alignment
>> requirement than double, its behavior would be undefined under any
>> implementation that imposes such an alignment.
>>
>> #include <stdio.h>
>>
>> typedef double pair[2];
>>
>> static void print(pair *p) {
>>     printf("%g %g\n", (*p)[0], (*p)[1]);
>> }
>>
>> int main(void) {
>>     double arr[3] = { 10.0, 20.0, 30.0 };
>>     pair *p0 = (pair*)&arr[0];
>>     pair *p1 = (pair*)&arr[1];
>>     print(p0);
>>     print(p1);
>> }
>
> If you mean the example program as part of an argument, it's
> a circular argument.  The program is strictly conforming if
> and only if the alignment of double[2] must be the same as
> the alignment of double.  Saying the given program is strictly
> conforming is just a sneaky way of begging the question.

It wasn't *quite* meant as an argument, more as a way to restate
the question in a perhaps clearer manner.

I *think* that C99 permits the kinds of access in this program (and
I'd be very surprised to see an implementation where it doesn't work)
but I haven't found wording that proves or disproves it.

[...]

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

#42908

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>> On 03/29/2014 03:57 AM, Keith Thompson wrote:
>>>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>> ...
>>>>>> Actually, that's precisely what double[2] is; and
>>>>>> _Alignof(double[2]) probably would be 16 on such a platform.
>>>>> 
>>>>> N1570 6.5.3.4p3:
>>>>> 
>>>>>     The _Alignof operator yields the alignment requirement of its
>>>>>     operand type. The operand is not evaluated and the result is
>>>>>     an integer constant. When applied to an array type, the result
>>>>>     is the alignment requirement of the element type.
>>>>
>>>> Ah - that's new, I think - I haven't had time to fully digest the
>>>> changes made in C2011. In principle the same requirement could have
>>>> been worded in earlier versions of the standard in terms of the
>>>> alignment of the type without mentioning _Alignof(), but I don't
>>>> think that it was.  Am I correct?
>>>
>>> Search for every occurrence of "alignment" in N1256, I see no
>>> explicit statement about the alignment of array types (which is a
>>> bit surprising).
>>>
>>> But I think the *required* alignment for an array type was already
>>> the same as the required alignment for the element type.
>>>
>>> For example, I *think* this program, which treats "slices" of a
>>> double[3] array as double[2] arrays, is strictly conforming in
>>> both C99 and C11.  If double[2] could have a stricter alignment
>>> requirement than double, its behavior would be undefined under any
>>> implementation that imposes such an alignment.
>>>
>>> #include <stdio.h>
>>>
>>> typedef double pair[2];
>>>
>>> static void print(pair *p) {
>>>     printf("%g %g\n", (*p)[0], (*p)[1]);
>>> }
>>>
>>> int main(void) {
>>>     double arr[3] = { 10.0, 20.0, 30.0 };
>>>     pair *p0 = (pair*)&arr[0];
>>>     pair *p1 = (pair*)&arr[1];
>>>     print(p0);
>>>     print(p1);
>>> }
>>
>> If you mean the example program as part of an argument, it's
>> a circular argument.  The program is strictly conforming if
>> and only if the alignment of double[2] must be the same as
>> the alignment of double.  Saying the given program is strictly
>> conforming is just a sneaky way of begging the question.
>
> It wasn't *quite* meant as an argument, more as a way to restate
> the question in a perhaps clearer manner.

I see.  How the comment is phrased makes it sound more like it's
meant to be an argument than a restatement.  So you might want
to make that distinction more clear.  But let's move on.

> I *think* that C99 permits the kinds of access in this program
> (and I'd be very surprised to see an implementation where it
> doesn't work) but I haven't found wording that proves or disproves
> it.

In the absence of any requirement that constrains an alignment
further, an implementation is free to choose the alignment of an
array type to be whatever it wants, subject to certain base
conditions (specifically the alignment of the element type must
evenly divide the alignment of the array type, and the alignment
of the array type must evenly divided the size of the type as a
whole, ie, a single instance of that array type).  So, unless
there is such a requirement, the example program may be subject
to undefined behavior (because the rule for converting pointer
types mentions undefined behavior explicitly when there are
alignment problems).  I think it's easy to see that there is no
such requirement in C99 -- simply check each occurrence of
"alignment" in the text, plus a review of the rules for pointer
conversion in section 6.3.2.3.  Is there something you can point
to that changes that?  If you can't, then I think it's reasonable
to say the point is settled and the above example program is not
strictly conforming under a strict technical reading of the
Standard.

By the way, I agree with your (implied?) point that the example
program is likely to work as expected on all currently existing
implementations, that most C developers expect that it would, and
that this result is what most of the Standards' authors would
expect also, at least as an unconscious assumption.  But I don't
think that result is guaranteed by a strict c.s.c-type reading
of C99 (or C90 either, but I haven't gone back to verify that).

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

#42321

James Kuyper <jameskuyper@verizon.net> writes:

> On 03/29/2014 03:57 AM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
> ...
>>> Actually, that's precisely what double[2] is; and _Alignof(double[2])
>>> probably would be 16 on such a platform.
>> 
>> N1570 6.5.3.4p3:
>> 
>>     The _Alignof operator yields the alignment requirement of its
>>     operand type. The operand is not evaluated and the result is
>>     an integer constant. When applied to an array type, the result
>>     is the alignment requirement of the element type.
>
> Ah - that's new, I think - I haven't had time to fully digest the
> changes made in C2011.  In principle the same requirement could
> have been worded in earlier versions of the standard in terms of
> the alignment of the type without mentioning _Alignof(), but I
> don't think that it was.  Am I correct?

Strictly speaking, no, but a more interesting question is since
_Alignof was mentioned specifically why not look it up in a more
up-to-date version of the Standard before responding, especially
knowing that one's knowledge of the 2011 standard (where _Alignof
is defined) is not really up to par yet?

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web