Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-02 Thread Wojtek Lerch via austin-group-l at The Open Group
e 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:shw

RE: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-02 Thread shwaresyst via austin-group-l at The Open Group
roup-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 i

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-02 Thread Steffen Nurpmeso via austin-group-l at The Open Group
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

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-02 Thread Steffen Nurpmeso via austin-group-l at The Open Group
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

RE: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-02 Thread Wojtek Lerch via austin-group-l at The Open Group
t; Sent: September 1, 2020 2:27 PM To: Wojtek Lerch mailto:wle...@blackberry.com>>; austin-group-l@opengroup.org<mailto:austin-group-l@opengroup.org> Subject: RE: [1003.1(2013)/Issue7+TC1 697]: Adding of a getdirentries() function I agree some additional clarity might be u

RE: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-02 Thread shwaresyst via austin-group-l at The Open Group
array is not a VLA, in the sense C uses the term.   From: shwaresyst Sent: September 1, 2020 4:55 PM To: Wojtek Lerch ; austin-group-l@opengroup.org Subject: RE: [1003.1(2013)/Issue7+TC1 697]: Adding of a getdirentries() function   What that refers to, it looks, is any tail padding

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-02 Thread Wojtek Lerch via austin-group-l at The Open Group
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?

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-02 Thread Joerg Schilling via austin-group-l at The Open Group
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

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-02 Thread Joerg Schilling via austin-group-l at The Open Group
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

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-02 Thread Geoff Clare via austin-group-l at The Open Group
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

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-02 Thread Geoff Clare via austin-group-l at The Open Group
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

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-02 Thread Geoff Clare via austin-group-l at The Open Group
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

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Philip Guenther via austin-group-l at The Open Group
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 The Open Group wrote in > |> <9252.1598969...@jinx.noi.kre.to>: >

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread shwaresyst via austin-group-l at The Open Group
No, that is not what I would want nor would anyone else. NAME_MAX doesn't guarantee no d_name will ever be longer than this value, what it says is all drivers for file systems provided by the implementation are capable of processing names up to that length. Some provided may support much

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Steffen Nurpmeso via austin-group-l at The Open Group
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 The Open Group wrote in |> <9252.1598969...@jinx.noi.kre.to>: |>|Date:Tue, 1 Sep 2020 10:32:55 +0100 |>|From:

RE: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Wojtek Lerch via austin-group-l at The Open Group
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 Sent: September 1, 2020 4:55 PM To: Wojtek Lerch ; austin-group-l@opengroup.org Subject: RE: [1003.1(2013)/Issue7+TC1 697]: Adding of a getdirentries() function What

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Steffen Nurpmeso via austin-group-l at The Open Group
shwaresyst wrote in <1739483391.1543785.1598977118...@mail.yahoo.com>: |No, it couldn't introduce such a macro, because such would have to \ |assume all d_name entries are the same length. Adding an option to \ Well it has to go for NAME_MAX + the_size_of_posix_dent for each and every entry,

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Steffen Nurpmeso via austin-group-l at The Open Group
Wojtek Lerch via austin-group-l at The Open Group wrote in : |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

RE: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread shwaresyst via austin-group-l at The Open Group
To: Wojtek Lerch ; austin-group-l@opengroup.org Subject: RE: [1003.1(2013)/Issue7+TC1 697]: 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

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Philip Guenther via austin-group-l at The Open Group
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 The Open Group wrote in > <9252.1598969...@jinx.noi.kre.to>: > |Date:Tue, 1 Sep 2020 10:32:55 +0100 > |From:"Geoff Clare via austin-group-l at

RE: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Wojtek Lerch via austin-group-l at The Open Group
@opengroup.org>; austin-group-l@opengroup.org<mailto:austin-group-l@opengroup.org> Subject: Re: [1003.1(2013)/Issue7+TC1 697]: 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 wa

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Philip Guenther via austin-group-l at The Open Group
On Tue, Sep 1, 2020 at 5:40 AM Geoff Clare via austin-group-l at The Open Group wrote: > > -- > > (0004958) philip-guenther (reporter) - 2020-08-30 23:06 > > https://austingroupbugs.net/view.php?id=6 >

RE: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread shwaresyst via austin-group-l at The Open Group
AM To: g...@opengroup.org; 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

RE: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Wojtek Lerch via austin-group-l at The Open Group
tin-group-l@opengroup.org Subject: Re: [1003.1(2013)/Issue7+TC1 697]: 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 padd

RE: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Wojtek Lerch via austin-group-l at The Open Group
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

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread shwaresyst via austin-group-l at The Open Group
No, it couldn't introduce such a macro, because such would have to assume all d_name entries are the same length. Adding an option to the interface to do a count, as a vararg parameter, and directly malloc the necessary space, returned via my suggested change to buf as a **, is plausible.

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Geoff Clare via austin-group-l at The Open Group
shwaresyst wrote, on 01 Sep 2020: > > 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 Thanks for the pointer. So it looks like removing "or equal to" is all that is needed here. > On Tuesday, September 1,

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Steffen Nurpmeso via austin-group-l at The Open Group
Geoff Clare via austin-group-l at The Open Group wrote in <20200901143300.GB24606@localhost>: |> -- |> (0004953) philip-guenther (reporter) - 2020-08-28 22:52 |> https://www.austingroupbugs.net/view.php?id=697#c4953 |>

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Steffen Nurpmeso via austin-group-l at The Open Group
Robert Elz via austin-group-l at The Open Group wrote in <9252.1598969...@jinx.noi.kre.to>: |Date:Tue, 1 Sep 2020 10:32:55 +0100 |From:"Geoff Clare via austin-group-l at The Open Group" \ | |Message-ID: <20200901093255.GA7629@localhost> | || but I'm not sure

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Geoff Clare via austin-group-l at The Open Group
> -- > (0004958) philip-guenther (reporter) - 2020-08-30 23:06 > https://austingroupbugs.net/view.php?id=697#c4958 > -- > The proposed text includes: >

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Geoff Clare via austin-group-l at The Open Group
> -- > (0004953) philip-guenther (reporter) - 2020-08-28 22:52 > https://www.austingroupbugs.net/view.php?id=697#c4953 > -- > I think the unspecified nature

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Geoff Clare via austin-group-l at The Open Group
> -- > (0004949) kre (reporter) - 2020-08-28 17:52 > https://www.austingroupbugs.net/view.php?id=697#c4949 > -- > I suspect that the intent of all of this is

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Robert Elz via austin-group-l at The Open Group
Date:Tue, 1 Sep 2020 10:32:55 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20200901093255.GA7629@localhost> | but I'm not sure how useful this would be to applications. In any case | it would be highly unusual for an application

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Geoff Clare via austin-group-l at The Open Group
Per Mildner wrote, on 30 Aug 2020: > > The posix_getdents() function shall ... place ... posix_dent structures in > the buffer pointed to by buf up to a maximum of nbyte bytes" > "The array d_name ... shall contain a filename of at most {NAME_MAX} bytes > followed by a terminating null byte."

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-08-30 Thread Per Mildner via austin-group-l at The Open Group
The posix_getdents() function shall ... place ... posix_dent structures in the buffer pointed to by buf up to a maximum of nbyte bytes" "The array d_name ... shall contain a filename of at most {NAME_MAX} bytes followed by a terminating null byte." (so could need up to {NAME_MAX} + 1 bytes).