Re: [PATCH v3 2/6] nptl: Add POSIX-proposed sem_clockwait

[Florian Weimer <fweimer at redhat dot com>]

* Mike Crowe:

> On Tuesday 25 June 2019 at 20:06:53 +0200, Florian Weimer wrote:
>> * Mike Crowe:
>> 
>> > On Wednesday 05 June 2019 at 18:07:18 -0300, Adhemerval Zanella wrote:
>> >> On 27/05/2019 17:03, Mike Crowe wrote:
>> >> > Add:
>> >> > 
>> >> >  int sem_clockwait (sem_t *sem, clockid_t clock, const struct timespec *abstime)
>> >> > 
>> >> > which behaves just like sem_timedwait, but measures abstime against the
>> >> > specified clock. Currently supports CLOCK_REALTIME and CLOCK_MONOTONIC and
>> >> > sets errno == EINVAL if any other clock is specified.
>> >> 
>> >> For non-POSIX definition we will need to first export it as a GNU extension
>> >> with a possible non-reserved name and later, when it is included on the 
>> >> standard, to add an alias to the expected name.  
>> >> 
>> >> The usual naming scheme is to append the _np suffix (non-portable) on 
>> >> implementation, similar to recent posix_spawn file action extensions.
>> >> In this case it would be sem_clockwait_np.
>> 
>> > I thought we went through this before[1] and agreed that the _np suffix wasn't
>> > necessary in this case. However, I couldn't find a reply to Florian
>> > agreeing to that.
>> 
>> Upon second thought, I agree with Adhemerval here.  We should use a
>> function with the _np suffix, otherwise we'll be in a world of pain if
>> something else is standardized.
>
> Well, the plan is to standardise this[1] and The Austin Group are the ones
> who decided on the names, but there needs to be an implementation before
> that can happen. Presumably that implementation can have _np suffixes in
> the short term though.
>
> I shall apply some sed to the patch series and repost.

Sorry, I see that we don't use _np for the other functions.
I'm confused now. 8-(

Adhemerval, is there value in keeping this consistent?  Have these
functions progressed to different stages in the POSIX process?

Thanks,
Florian