This issue is under discussion again in the C23 ballot resolution. The current POSIX standard has the type for tv_nsec as a long, and there is, to my knowledge, no proposal from the Austin Group to change it. Geoff's suggestion that perhaps changing this type might be acceptable is being taken as approval from the AG that such a change should go into C2x. As liaison to C, I propose to refute this during the upcoming ballot resolution meeting unless someone can persuade me I'm wrong!
On Fri, May 20, 2022 at 2:42 AM Geoff Clare via austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote: > Fred J. Tydeman wrote, on 19 May 2022: > > > > On Wed, 18 May 2022 09:30:51 +0100 Geoff Clare via austin-group-l at The > Open Group wrote: > > > > > >Fred J. Tydeman wrote, on 17 May 2022: > > >> > > >> The 202x version I have, in <time.h>, shows tv_nsec tagged as CX. > > >> tv_nsec was added to C11, so is not an extension to the C standard. > > > > > >The current draft (2.1) is from before the changes to align with C17 > > >were applied. > > > > > >The relevant change to <time.h> can be seen on page 26 lines 928-935 > > >of C17_alignment_20211019.pdf which is the bug 1302 attachment > > >referenced in the "Final Accepted Text" field of that bug. > > > > > >https://austingroupbugs.net/view.php?id=1302 > > > > > > > Would it be OK if the C committee changed the type of tv_nsec from 'long' > > to an implementation defined type? That way, an implementation could > > make it be a 32-bit int, instead of a 64-bit long. > > > > Or, would that change cause problems for existing applications? > > It would mean that any code which formats a tv_nsec using %ld would > need to change to add a cast to the argument. > > However, several similar changes have been made in the past (with the > same effect on existing code), so perhaps this would be considered > acceptable. > > > The paper: > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2878.pdf > > is being discussed at this week's WG14 meeting. > > The Linux issue raised there has been discussed here in the past (2014) > and was considered simply a bug that either glibc or the kernel should > fix. > > -- > Geoff Clare <g.cl...@opengroup.org> > The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England > >
