Re: adding errc to support sed (FreeBSD)

[Rich Felker <dalias@libc.org>]

On Sat, May 03, 2014 at 06:38:40PM -0700, Isaac Dunham wrote:
> On Sat, May 03, 2014 at 08:04:53PM -0400, 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?
> > 
> 
> There's errc(), verrc(), warnc(), and vwarnc().
> All the *c variants add "int code" before char *fmt (int status in the 
> example above), which allows passing an error that is not stored in errno.
> 
> eg:
> void errc(int eval, int code, const char *fmt, ...);
> void verrc(int eval, int code, const char *fmt, va_list args);
> void warnc(int code, const char *fmt, ...);
> void vwarnc(int code, const char *fmt, va_list args);
> > > 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.
> ALLPERMS and DEFFILEMODE are in sys/stat.h.
> ALLPERMS is 07777; DEFFILEMODE is 0666.

Yes. these are pretty unwelcome then...

> REG_STARTEND is in regex.h.

I believe it's actually in a reserved namespace.

> > As for REG_STARTEND, is it an alias for some regex flag that already
> > exists, or a feature that would need to be implemented?
> It's an extension to POSIX that got mentioned here in January of last year;
> it reuses pmatch[0] to provide a start and end (so as to handle embedded
> nulls or start after n bytes).

In that case it's not trivial to provide; it requires making the
internal regex code significantly larger/slower because it has to be
able to check for either exceeding a count or hitting zero everywhere,
rather than just checking for a zero byte. (Actually start is trivial,
but end isn't.)

Rich