Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 3 May 2014 21:54:02 -0400
From: Rich Felker <>
Subject: Re: adding errc to support sed (FreeBSD)

On Sat, May 03, 2014 at 09:34:41PM -0400, wrote:
> On 05/03/2014 08:04 PM, Rich Felker wrote:
> >On Sat, May 03, 2014 at 07:58:48PM -0400, 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.)

> >>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:


> >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


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.