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
On 2020-09-02 10:34, Joerg Schilling wrote:
Wojtek Lerch via austin-group-l at The Open Group
wrote:
A structure member can be a "flexible array" in standard C, but that's not the
same thing as a VLA.
Are you speaking about array[] in contrast to array[size] with size being
On Thu, 2020-09-03 at 00:31 +, 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
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
That sounds a little backwards – it’s everything 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 say how much greater the
Geoff Clare wrote:
> We can't require d_name in struct dirent to be a VLA since there are
> implementations where it is not.
Another good reason is that standard C does not allow structure members to be
VLAs.
C11 6.7.2.1#9 "A member of a structure or union may have any complete object
type
Actually the intent was the opposite. The original C99 did contain a wording
that matches your interpretation:
… the size of the structure shall 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
Geoff Clare wrote:
> For fread(), the return type is size_t not ssize_t, so it doesn't
> have quite the same problem. The question is what should happen if
> the mathematical product of the size and nitems arguments is greater
> than SIZE_MAX. POSIX defers to the C standard on this and there is
Robert Elz wrote:
>From:"Geoff Clare via austin-group-l at The Open Group"
>
> | Isn't an array whose total size exceeds SIZE_MAX bytes an impossibility?
>
> It is, [...]
Chapter and verse please? :)
> Of course, any application that attempts to test this is going to result in a
Geoff Clare wrote:
> Wojtek Lerch wrote, on 07 Oct 2020:
> > Geoff Clare wrote:
> > > For fread(), the return type is size_t not ssize_t, so it doesn't
> > > have quite the same problem. The question is what should happen if
> > > the mathematical product of the size and nitems arguments is
10 matches
Mail list logo
