[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5365A82C.1070509@midipix.org>
Date: Sat, 03 May 2014 22:38:36 -0400
From: "writeonce@...ipix.org" <writeonce@...ipix.org>
To: musl@...ts.openwall.com
Subject: Re: adding errc to support sed (FreeBSD)
On 05/03/2014 09:54 PM, Rich Felker wrote:
> On Sat, May 03, 2014 at 09:34:41PM -0400, writeonce@...ipix.org wrote:
>> On 05/03/2014 08:04 PM, Rich Felker wrote:
>>> On Sat, May 03, 2014 at 07:58:48PM -0400, writeonce@...ipix.org wrote:
>>>> Greetings,
>>>>
>>>> The FreeBSD implementation of sed uses errc; its implementation
>>>> should probably be as simple as:
>>>>
>>>> _Noreturn void errc(int eval, int status, const char *fmt, ...)
>>>> {
>>>> va_list ap;
>>>> va_start(ap, fmt);
>>>> vwarnx(status, fmt, ap);
>>>> va_end(ap);
>>>> exit(eval);
>>>> }
>>> What's the difference between this and other forms in err.h? Is there
>>> a 'v' version of it too?
>> The missing feature seems to consist in an exit code (eval) that
>> could be distinct from the error code (status).
> I would at least rename the argument and refactor a bit, but I think
> this is probably acceptable to add. (Normally "status" means exit
> status; I have no idea what "eval" means. I would call them "status"
> and "error" rather than "eval" and "status", respectively.)
I'm not sure what _eval_ means either, but that's the argument used by
FreeBSD;-) "status" and "error" (or "code" or "errcode") definitely works.
>
>>>> The FreeBSD sed also needs a couple of macros that are currently not
>>>> defined, specifically ALLPERMS, DEFFILEMODE and REG_STARTEND. Any
>>>> reason not to add them when _BSD_SOURCE is defined?
>>> Where would these be defined? If they're in a junk header I'm not so
>>> opposed to them, but musl aims to have a cleaner namespace than legacy
>>> systems, whereas at least ALLPERMS and DEFFILEMODE are ugly and don't
>>> fit any sort of namespace pattern.
>> I agree they are ugly, but unfortunately they're also essential for
>> most bsd utilities to build. As a hopefully non-intrusive solution,
>> I wanted to suggest a new sys/bsd.h header, to be conditionally
>> included from within alltypes.h when _BSD_SOURCE is defined.
> That's definitely not appropriate; I'm not sure why alltypes seems
> like a natural place to put it. FYI _BSD_SOURCE is the default.
>
> Anyway, these programs should just be fixed at the source level, but
> they can also easily be fixed by CFLAGS:
>
> -DALLPERMS=07777 -DDEFFILEMODE=0666
Yes, but there are also some bsd-specific macros that cannot be defined
from the command line since they take arguments. If not provided by
musl, a separate header would still need to exist and be included via
--include=bsd.h
With _BSD_SOURCE being the default, a useful compromise might be to 1)
provide bsd.h for compatibility with bsd utilities; and 2) have users
manually include that file via --include=<sys/bsd.h>
Does that work?
>
>>> As for REG_STARTEND, is it an alias for some regex flag that already
>>> exists, or a feature that would need to be implemented?
>> Apparently REG_STARTEND is not a simple #define as the other macros,
>> but rather a flag that is accounted for in _regcomp_. The feature
>> itself is not too complicated, though, and seems to add only a few
>> lines of code to the FreeBSD implementation of regex.
> Being trivial in one implementation doesn't necessarily make it
> trivial in another. The start part is trivial, but the end part is
> not.
>
> Rich
>
>
I see. Do you see any chance of looking into this for possible
inclusion in musl? For most scenarios a no-op (defined as zero)
REG_STARTEND should work, but that's far from ideal.
zg
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.
