mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: adding errc to support sed (FreeBSD)
Date: Sat, 3 May 2014 21:54:02 -0400	[thread overview]
Message-ID: <20140504015402.GB17064@brightrain.aerifal.cx> (raw)
In-Reply-To: <53659931.2020309@midipix.org>

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

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

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


  reply	other threads:[~2014-05-04  1:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-03 23:58 writeonce
2014-05-04  0:04 ` Rich Felker
2014-05-04  1:34   ` writeonce
2014-05-04  1:54     ` Rich Felker [this message]
2014-05-04  2:38       ` writeonce
2014-05-04  3:20         ` M Farkas-Dyck
2014-05-04  3:49           ` writeonce
2014-05-04  1:38   ` Isaac Dunham
2014-05-04  1:50     ` Rich Felker
2014-05-04  0:20 ` Anthony J. Bentley
2014-05-04  0:23   ` Anthony J. Bentley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140504015402.GB17064@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).