Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.