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 ev
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. This is why the language is
padding bytes may be added, not shall be added. The standard
Hallo Jörg.
Joerg Schilling wrote in
<5f4fabb0.NZ6ZB9gXMVdfs/6x%joerg.schill...@fokus.fraunhofer.de>:
|Steffen Nurpmeso via austin-group-l at The Open Group wrote:
|
|> I personally would say that these should be skipped. The data is
|> copied over to user buffers, and these entries are sim
Philip Guenther via austin-group-l at The Open Group wrote in
:
|On Tue, Sep 1, 2020 at 1:20 PM Steffen Nurpmeso wrote:
|> Philip Guenther wrote in
|> :
|>|On Tue, Sep 1, 2020 at 6:22 AM Steffen Nurpmeso via austin-group-l at The
|>|Open Group wrote:
|>|> Robert Elz via austin-group-l at
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
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 afte
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 a
variable?
Y
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 a
variable?
Jörg
--
EMail:jo...@schily.net
Steffen Nurpmeso via austin-group-l at The Open Group
wrote:
> I personally would say that these should be skipped. The data is
> copied over to user buffers, and these entries are simply not
> copied. That seems to be the best. The Group does not seem to
> want to add DT_WHITEOUT or similar
Steffen Nurpmeso wrote, on 01 Sep 2020:
>
> |Do the existing implementations ever return such things? Do they
> |hide them by making the reclen of the previous entry (if there is
> |one in the buffer) bigger, or do they squash them out, moving the
> |next existing entry down to follow immedi
Philip Guenther wrote, on 01 Sep 2020:
>
> If a posix_getdents() implementation returned the names of all the files
> that ever existed in the given directory, including ones that were removed
> before the fd for this call was opened, what requirement in the standard
> would that violate? I don't
Wojtek Lerch wrote, on 01 Sep 2020:
>
> 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.
Mea culpa. I tried to save some typ
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1396
==
Reported By:rillig
Assigned To:
=
13 matches
Mail list logo