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. Since we are merging 
common behaviors with this interface introduction, not describing a single 
reference implementation, such changes are permitted if someone commits to 
doing an implementation, afaik.
On Tuesday, September 1, 2020 Steffen Nurpmeso via austin-group-l at The Open 
Group <stef...@sdaoden.eu> wrote:
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 
 |> ---------------------------------------------------------------------- 
 |> I think the unspecified nature of the d_name member in the new posix_dent
 |> makes writing portable software more difficult while providing only \
 |> minimal
 |> benefit to programs that don't care.  I would support requiring it \
 |> to be a
 |> flexible array member and thus eliminating the error of declaring \
 |> an array
 |> and trying to walk it via indexing instead of by advancing a char pointer
 |> by d_reclen.
 |
 |I think we should keep the requirements for d_name the same between
 |struct dirent and struct posix_dent.  Some implementations of
 |getdents() and getdirentries() use struct dirent and they should be
 |able to make posix_getdents() a synonym (or a light wrapper) for the
 |existing function by making struct posix_dent be identical to struct
 |dirent.  We can't require d_name in struct dirent to be a VLA since
 |there are implementations where it is not.

The standard could also introduce a macro which could be used to
space a buffer accordingly, something like (very ugly)
POSIX_GETDENTS_BYTES_FOR_DENTS(number-of-desired-dents), and use
it in the example.
Like that any possible errors with buffer space allocation would
not even be introduced (except for possible integer overflows,
maybe).

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter          he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

  • [1003.1(2013... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2013... Austin Group Bug Tracker via austin-group-l at The Open Group
    • Re: [10... Geoff Clare via austin-group-l at The Open Group
      • Re:... Philip Guenther via austin-group-l at The Open Group
        • ... Geoff Clare via austin-group-l at The Open Group
  • [1003.1(2013... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2013... Austin Group Bug Tracker via austin-group-l at The Open Group
  • Re: [1003.1(... shwaresyst via austin-group-l at The Open Group
    • Re: [10... Geoff Clare via austin-group-l at The Open Group
    • RE: [10... Wojtek Lerch via austin-group-l at The Open Group
  • Re: [1003.1(... shwaresyst via austin-group-l at The Open Group
    • Re: [10... Steffen Nurpmeso via austin-group-l at The Open Group
  • RE: [1003.1(... shwaresyst via austin-group-l at The Open Group
    • RE: [10... Wojtek Lerch via austin-group-l at The Open Group
  • RE: [1003.1(... shwaresyst via austin-group-l at The Open Group
    • RE: [10... Wojtek Lerch via austin-group-l at The Open Group
  • Re: [1003.1(... shwaresyst via austin-group-l at The Open Group
  • RE: [1003.1(... shwaresyst via austin-group-l at The Open Group
    • RE: [10... Wojtek Lerch via austin-group-l at The Open Group
  • RE: [1003.1(... shwaresyst via austin-group-l at The Open Group
    • Re: [10... Wojtek Lerch via austin-group-l at The Open Group

Reply via email to