On Fri, 20 Jan 2023, Geoff Clare via austin-group-l at The Open Group wrote:
> Nick Stoughton wrote, on 19 Jan 2023:
> >
> > 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,
Date:Fri, 20 Jan 2023 08:37:44 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| You haven't stated your reasons for wanting to refute it, so that makes
| it difficult to know what we can say to persuade you you're wrong.
Nick also
Nick Stoughton wrote, on 19 Jan 2023:
>
> 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
>
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
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 , shows tv_nsec tagged as CX.
> >> tv_nsec was added to C11, so is not an
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 , 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
Fred J. Tydeman wrote, on 17 May 2022:
>
> The 202x version I have, in , 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 can be seen on