Re: Please vote: should we fix or drop the usleep() function?

On 21/11/14 06:55, Yongwei Wu wrote:
> Why breaking something already working (mostly)? I do not see Cygwin
> or Linux is dropping usleep.

AIUI, Linux requires certain feature test macros to be specified, and
Linux' glibc-2.12 (and later) *does* remove it, (or so the manpage
implies), for applications which correctly specify _POSIX_C_SOURCE >=
200809L, or _XOPEN_SOURCE >= 700, (or which neglect to specify earlier
versions of these, or alternative enabling macros[1]).

[1] However, trivial testing would appear to refute this latter claim!
The former *is* honoured, insofar as the prototype is removed from
unistd.h, (resulting in a GCC warning), but the library implementation
remains exposed for linking.

> We could even leave it as it is, since it is no longer standard

I'm not in favour of retaining *anything* in a broken state!  However,
*I* don't object to retaining it if it is fixed, although others here
have objected, in the past, to including support for anything which is
not MS standard, ISO-C standard, or (with some reluctance) POSIX, and
since POSIX.1-2008, usleep() is none of these.

> (though fixing something is always good, esp. if it is easy).

It is trivially easy to fix ... just remove the faulty test altogether,
since POSIX never *required* it to fail for the specified reason[2].

[2] FWIW, POSIX said it *may* (optionally) fail for a specified sleep
interval in excess of 999,999 microseconds; Linux' glibc implementation
*doesn't* impose this limitation.

> I guess no one is actually checking the return value of usleep, anyway.

I don't think I would go as far as to say that; perhaps no one is using
it in a manner in which it fails ... which requires a specified sleep
interval in excess of 999,999 microseconds.  What we can say is that,
those who are using it in failing manner either aren't checking for
success, or are interpreting the failure mode improperly; either could
be construed as an application bug.  (I believe NetBSD may fail in this
same circumstance, with the correct error return state).

> My 2 cents.

For which I'm grateful, since right now, no one else seems to be
bothered enough to respond urgently.

-- 
Regards,
Keith.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk