adding errc to support sed (FreeBSD)

adding errc to support sed (FreeBSD)

[writeonce]

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);
}

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?

Kind regards,
zg

Re: adding errc to support sed (FreeBSD)

[Rich Felker]

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

As for REG_STARTEND, is it an alias for some regex flag that already
exists, or a feature that would need to be implemented?

Rich

Re: adding errc to support sed (FreeBSD)

[Anthony J. Bentley]

"writeonce@midipix.org" writes:
> 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);
> }

If you add this then you should probably implement verrc, warnc, and
vwarnc as well.

These functions exist in FreeBSD, NetBSD, and OS X and are probably
going to be added to OpenBSD soon.

-- 
Anthony J. Bentley

Re: adding errc to support sed (FreeBSD)

[Anthony J. Bentley]

"Anthony J. Bentley" writes:
> "writeonce@midipix.org" writes:
> > 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);
> > }
> 
> If you add this then you should probably implement verrc, warnc, and
> vwarnc as well.
> 
> These functions exist in FreeBSD, NetBSD, and OS X and are probably
> going to be added to OpenBSD soon.

Actually they are already in OpenBSD too.

-- 
Anthony J. Bentley

Re: adding errc to support sed (FreeBSD)

[writeonce]

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

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

>
> As for REG_STARTEND, is it an alias for some regex flag that already
> exists, or a feature that would need to be implemented?
>
> Rich
>
>

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.

zg

Re: adding errc to support sed (FreeBSD)

[Isaac Dunham]

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.
REG_STARTEND is in regex.h.
> 
> 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).

> Rich

HTH,
Isaac Dunham

Re: adding errc to support sed (FreeBSD)

[Rich Felker]

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

Re: adding errc to support sed (FreeBSD)

[Rich Felker]

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

Re: adding errc to support sed (FreeBSD)

[writeonce]

On 05/03/2014 09:54 PM, Rich Felker wrote:
> 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.)
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

Re: adding errc to support sed (FreeBSD)

[M Farkas-Dyck]

On 03/05/2014, writeonce@midipix.org <writeonce@midipix.org> wrote:
> Yes, but there are also some bsd-specific macros that cannot be defined
> from the command line since they take arguments.

Such macros can be so defined with GNU and OpenBSD cpp at least; what is yours?

Re: adding errc to support sed (FreeBSD)

[writeonce]

On 05/03/2014 11:20 PM, M Farkas-Dyck wrote:
> On 03/05/2014, writeonce@midipix.org <writeonce@midipix.org> wrote:
>> Yes, but there are also some bsd-specific macros that cannot be defined
>> from the command line since they take arguments.
> Such macros can be so defined with GNU and OpenBSD cpp at least; what is yours?
>
>
You are right; what I experienced with llvm/clang was unrelated to the 
command-line macro arguments.