[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.1602292252300.14767@monopod.intra.ispras.ru>
Date: Mon, 29 Feb 2016 22:59:10 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] add sched_getcpu
On Mon, 29 Feb 2016, Rich Felker wrote:
> > (this include could also be dropped; I think it's a matter of policy whether
> > such includes are desirable or not, so please wait for comment from Rich)
>
> Policy is to always include the header with the public declaration
> (and any feature test macros necessary to get it) so that the compiler
> checks the implementation against the public declaration.
This policy certain makes sense; I pointed that out because I've seen it
violated; at least the following files violate it by defining something
without including anything:
arch/arm/src/__aeabi_atexit.c
src/internal/procfdname.c
src/misc/gethostid.c
src/prng/__seed48.c
src/signal/restore.c
src/signal/sigrtmin.c
src/stdlib/abs.c
src/stdlib/labs.c
src/stdlib/llabs.c
src/time/__month_to_secs.c
src/time/__year_to_secs.c
(but e.g. in procfdname.c there's nothing to include because every caller
declares the prototype, and also hardcodes the buffer size -- see my recent
patch)
> > This is wrong, as it doesn't set errno on error, and does not produce -1. This
> > should be something like 'return s ? __syscall_ret(s) : c;' or maybe
> > 'return __syscall_ret(s ? s : c);'.
>
> Why is an error even possible here? Is it just to account for ancient
> kernels that lack the syscall?
Apparently so -- afaics current kernels can only produce EFAULT, which cannot
happen in this case.
(I was wrong about the need to use __syscall_ret, but that's for another
subthread)
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
