[mpich-discuss] Erroneous MPI type tag warning

[Jed Brown]

Markus Geimer <m.geimer at fz-juelich.de> writes:
> Well, according to the C99 standard "Each non-bit-field member of a
> structure or union object is aligned in an *implementation-defined*
> manner appropriate to its type." (§6.7.2.1) It is therefore not
> guaranteed that the two ints in the struct are contiguous -- which
> means that, strictly speaking, int[2] is the only portable choice.
> (Although I'm not aware of any compiler that would insert padding
> between the two ints, i.e., in practice the struct should be fine,
> too.)

C11 adds the _Alignof operator and elaborates further on alignment.
Although the wording is ambiguous in the section on structs, I think the
intent is clear that the "implementation-defined" alignment is indeed
the implementation-defined value returned by _Alignof and discussed in
C11 §6.2.8 Alignment of objects:

  Complete object types have alignment requirements which place
  restrictions on the addresses at which objects of that type may be
  allocated. An alignment is an implementation-defined integer value
  representing the number of bytes between successive addresses at which
  a given object can be allocated. An object type imposes an alignment
  requirement on every object of that type: stricter alignment can be
  requested using the _Alignas keyword.

_Alignof cannot reasonable return a value larger than sizeof, for that
would break idioms such as (§6.5.3.4.7)

  sizeof array / sizeof array[0]

Anyway, alignment rules apply everywhere, not just in structs, so there
can be no difference in layout between

  typedef int array_2int[2];

and

  typedef struct {int value,loc;} struct_2int;

The reiteration of "implementation-defined" in the section on structs is
likely because that is a place where alignment semantics are directly
observable (versus allocation of automatic/stack variables).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20131225/ba0fa55d/attachment.sig>