On Thu, 2020-09-03 at 00:31 +0000, shwaresyst wrote: > No, it does not need to be aligned to a multiple of 4, except on some > lame RISC architectures. The logical model is unaligned accesses are > always permitted; aligned accesses are the exception, not the rule.
No, the logical model is that every type has an implementation-defined alignment requirement, and attempting to access an object that does not meet the requirement, or even just to produce a pointer to such an object, results in undefined behavior. An implementation can choose to define the alignment of all types to be 1, allowing unrestricted placement of objects, but that's a special case, not the rule. C11 6.2.8#1: 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. C11 6.3.2.3#7 A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined. > This is why the language is padding bytes may be added, not shall be > added. No, the reason it says "may" is because it depends on the types of members and their implementation-defined alignment requirements. (Also, as far as I can tell an implementation is not forbidden to add more padding than required by alignment; but I have not heard of one that does that.) > The standard expects applications to use int_fastN_t or > int_leastN_t types if it wants to take advantage of platform specific > alignment optimizations. Not exactly. The requirements on int_leastN_t have nothing to do with alignment or optimizations -- they're only based on the existence of types with particular widths. The requirements on int_fastN_t are generally about speed, not specifically alignment. On hardware where 32-bit access is faster than 16-bit access, "int_fast16_t" could be defined as a 32-bit type (but yes, if unaligned 32-bit access is allowed but slow, the implementation will likely use _Alignas to speed it up). > The allocation functions only recently added > the only alignment requirement, namely any pointer returned be > aligned for an access to an intmax_t value, and the region be > minimally sizeof(intmax_t) in length. I think you meant max_align_t? There's indeed some new wording in C11 that tightens up the specification of alignment, but the concept of alignment and the requirement on allocation functions is not new. Compare the two fragments I quoted from C11 above with these from C99: C99 3.2#1 alignment -- requirement that objects of a particular type be located on storage boundaries with addresses that are particular multiples of a byte address C99 6.3.2.2#7 A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned for the pointed-to type, the behavior is undefined. And these about allocation functions: C99 7.20.3#1 The order and contiguity of storage allocated by successive calls to the calloc, malloc, and realloc functions is unspecified. The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated). C11 7.22.3#1 The order and contiguity of storage allocated by successive calls to the aligned_alloc, calloc, malloc, and realloc functions is unspecified. The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated). > On Wednesday, September 2, 2020 Wojtek Lerch <mailto:wle...@blackberry.com> > wrote: > #yiv9121566835 #yiv9121566835 -- _filtered {} _filtered {} _filtered > {}#yiv9121566835 #yiv9121566835 p.yiv9121566835MsoNormal, > #yiv9121566835 li.yiv9121566835MsoNormal, #yiv9121566835 > div.yiv9121566835MsoNormal {margin:0cm;margin-bottom:.0001pt;font- > size:11.0pt;font-family:sans-serif;}#yiv9121566835 a:link, > #yiv9121566835 span.yiv9121566835MsoHyperlink {color:blue;text- > decoration:underline;}#yiv9121566835 p.yiv9121566835MsoPlainText, > #yiv9121566835 li.yiv9121566835MsoPlainText, #yiv9121566835 > div.yiv9121566835MsoPlainText {margin:0cm;margin-bottom:.0001pt;font- > size:11.0pt;font-family:sans-serif;}#yiv9121566835 > p.yiv9121566835msonormal, #yiv9121566835 li.yiv9121566835msonormal, > #yiv9121566835 div.yiv9121566835msonormal {margin-right:0cm;margin- > left:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv9121566835 > p.yiv9121566835msonospacing1, #yiv9121566835 > li.yiv9121566835msonospacing1, #yiv9121566835 > div.yiv9121566835msonospacing1 {margin-right:0cm;margin- > left:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv9121566835 > p.yiv9121566835msonormal4, #yiv9121566835 li.yiv9121566835msonormal4, > #yiv9121566835 div.yiv9121566835msonormal4 {margin-right:0cm;margin- > left:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv9121566835 > p.yiv9121566835msonormal31, #yiv9121566835 > li.yiv9121566835msonormal31, #yiv9121566835 > div.yiv9121566835msonormal31 {margin-right:0cm;margin-left:0cm;font- > size:11.0pt;font-family:sans-serif;}#yiv9121566835 > span.yiv9121566835EmailStyle36 {font-family:New > serif;color:windowtext;}#yiv9121566835 > span.yiv9121566835PlainTextChar {font-family:sans- > serif;}#yiv9121566835 .yiv9121566835MsoChpDefault {font-size:10.0pt;} > _filtered {}#yiv9121566835 div.yiv9121566835WordSection1 > {}#yiv9121566835 > Yes I made the flexible member a "short" on purpose -- I wanted that > byte of padding before the flexible array. > > > > No, the sizeof can't be 5 or 6 unless the implementation is okay with > unaligned access. If I declare an array of these structs, the int32 > inside each element needs to be aligned to a multiple of 4 -- > therefore the size of the struct must be a multiple of 4 as well. > The same applies to a struct without a flexible member. > > > > No, the requirements on sizeof have nothing to do with how many flex > members are "present". All that is required is that the sizeof is > either the same as it would be for a struct without the flexible > member (which is still 8, on any implementation that requires > alignment), or greater, if the struct requires more padding > (presumably also for alignment). Apart from that, the C standard > says nothing about whether there's enough room between the offsetof > and the sizeof for one or more elements of the flexible array. > > > > What you described with malloc() has nothing to do with what the C > standard refers to as “padding”. > > > > Also, while I understand the need to page-align data structures in > some situations, I still don’t see its relevance to a discussion of > the C standard’s requirements regarding padding in struct types and > how it’s affected by flexible arrays. > > > > From: shwaresyst <mailto:shwares...@aol.com> > Sent: September 2, 2020 1:58 PM > To: Wojtek Lerch <mailto:wle...@blackberry.com>; > mailto:austin-group-l@opengroup.org > Subject: RE: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a > getdirentries() function > > > > That example still has a byte of added padding, or the offsetof would > be 5. The sizeof value is just incorrect, as it assumes one flex > member is present. It should be 5 or 6, and which is the required > value is what is ambiguous. > > As you say, these are used most often with malloc(). Padding after > the array is usually an artifact of this operation. You do a > malloc(12) and you may get 16 or 32 bytes actually allocated. Mapping > this as a short s[] an application can safely access s[5], but a > compiler may not block an access to s[7] too, in that the memory for > it is allocated. You map a long long l[] and you can only access l[0] > safely, the remaining 4 bytes out of the 12 plus what malloc adds are > tail padding, but a compiler may allow an l[1] access because the > total allocated permits it. > > I mentioned page aligned because when you are buffering multiple > sectors directly from media the malloc()s for these will usually be > in multiples of pages, and efficient management of these happens when > these don't straddle pages so are page aligned too. Such isn't > required by the standard, but it's common enough as desirable > aligned_alloc() was added. As I've seen no one use FLA as an acronym > for flexible array, I consider VLA as applying to any array of > indeterminate size, sorry if this confuses anyone. > > > > On Tuesday, September 1, 2020 Wojtek Lerch <mailto:wle...@blackberry.com> > wrote: > > My understanding is that they meant to allow an implementation where > “struct a { int32_t x; char y; short flex[]; }” produces > sizeof(struct a)==8 but offsetof(struct a,flex)==6. > > > > I don’t like that they talk about padding “after” the flexible member > – since the flexible array has a flexible size, rather than a zero > size, that padding really overlaps the beginning of the array. > > > > Personally I think that the standard could be made clearer if a > structure with a flexible member were considered an incomplete type. > You wouldn’t be allowed to applysizeof to it at all, and you wouldn’t > be able to declare objects whose type is the structure, but you could > still use pointers to it and dereference members – since the main > purpose of such structures is to allocate them via malloc(), I don’t > think anybody would mind those restrictions. > > > > Also, I don’t understand whystruct s would need to be page aligned or > why you mention a VLA. A flexible array is not a VLA, in the sense C > uses the term. > > > > From: shwaresyst <mailto:shwares...@aol.com> > Sent: September 1, 2020 4:55 PM > To: Wojtek Lerch > <mailto:wle...@blackberry.com>;mailto:austin-group-l@opengroup.org > Subject: RE: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a > getdirentries() function > > > > What that refers to, it looks, is any tail padding for the structure > as a whole. The standard still permits internal padding between > individual fields as required, e.g. a struct s { short a; double b[] > } might need 6 bytes of this padding to align access for b[0]. This > would still be needed if b[] only has a few members as a VLA but s is > being page aligned, and so would reserve a lot of tail padding too. > There would be 2 padding regions, however, is what that change > forces. > > > > On Tuesday, September 1, 2020 Wojtek Lerch <mailto:wle...@blackberry.com> > wrote: > > Actually the intent was the opposite. The original C99 did contain a > wording that matches your interpretation: > > > > … the size of the structureshall be equal to the offset of the last > element of an otherwise identical structure that replaces the > flexible array member with an array of unspecified length. > > > > But this was reported as a defect, and corrected in TC2. > > > > Summary > 6.7.2.1 Structure and union specifiers, paragraphs 15 and 16 require > that any padding for alignment of a structure containing a flexible > array member must preceed the flexible array member. This > contradicts existing implementations. We do not believe this was the > intent of the C99 specification. > > Details > > If a struct contains a flexible array member and also requires > padding for alignment, then the current C99 specification requires > the implementation to put this paddingbefore the flexible array > member. However, existing implementations, including at least GNU C, > Compaq C, and Sun C, put the paddingafter the flexible array member. > > The layout used by existing implementations can be more efficient. > Furthermore, requiring these existing implementations to change their > layout would break binary backwards compatibility with previous > versions. > > > > See DR282 for more details: > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.open-2Dstd.org_jtc1_sc22_wg14_www_docs_dr-5F282.htm&d=DwIFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=-4AKPdl-tTThW9baWRqks1QhV4BtauX1oWrciJm2KH8&m=UKGmPQPkI5BgtWOwMUGskmsXmrScwinWaMRKrzQ85vc&s=BBJvvOYRLRxUevDB81NEfqwXW_AN45gKtvFPPfDUA3E&e= > > > > > > > From: shwaresyst <mailto:shwares...@aol.com> > Sent: September 1, 2020 2:27 PM > To: Wojtek Lerch > <mailto:wle...@blackberry.com>;mailto:austin-group-l@opengroup.org > Subject: RE: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a > getdirentries() function > > > > I agree some additional clarity might be useful there, in the C > standard. I'm reading it as the intent being sizeof is equivalent to > offsetof the VLA in accordance with the restrictions placed on it by > use of the . or -> operators, which may not need extra bytes (so &s- > >vla == (&s + sizeof(s)) is a truism, in other words) but it is not > that specific. > > > > On Tuesday, September 1, 2020 Wojtek Lerch <mailto:wle...@blackberry.com> > wrote: > > That sounds a little backwards – it’severything else that works as if > the flexible (not “variable”) member were not present. The sizeof > operator, as an exception, can return a greater value. (The “.” and > “->” operators are another exception.) > > > > The standard does not sayhow much greater the value may be, or > promise that it must be greater, even if padding is necessary to > align the flexible member – as far as I can tell, sizeof(structure) > can beless than offsetof(structure, flexible). > > > > From: mailto:austin-group-l@opengroup.org > <mailto:austin-group-l@opengroup.org> > Sent: September 1, 2020 10:52 AM > To: mailto:g...@opengroup.org;mailto:austin-group-l@opengroup.org > Subject: Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a > getdirentries() function > > > > It's my understanding, by C11 6.7.2.1p18, sizeof on a struct with a > variable array works as if the variable member was not present, but > does count any bytes added for alignment padding, as this will be a > fixed amount for each use of the struct. It is up to the application, > like with variable argument lists, to establish a protocol that > allows it to determine the effective size of the final member. > > This transmission (including any attachments) may contain > confidential information, privileged material (including material > protected by the solicitor-client or other applicable privileges), or > constitute non-public information. Any use of this information by > anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission by > unintended recipients is not authorized and may be unlawful. > > > > This transmission (including any attachments) may contain > confidential information, privileged material (including material > protected by the solicitor-client or other applicable privileges), or > constitute non-public information. Any use of this information by > anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission by > unintended recipients is not authorized and may be unlawful. > > This transmission (including any attachments) may contain > confidential information, privileged material (including material > protected by the solicitor-client or other applicable privileges), or > constitute non-public information. Any use of this information by > anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission by > unintended recipients is not authorized and may be unlawful. > This transmission (including any attachments) may contain > confidential information, privileged material (including material > protected by the solicitor-client or other applicable privileges), or > constitute non-public information. Any use of this information by > anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission by > unintended recipients is not authorized and may be unlawful. ---------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
