xfuncs, bb_ funcs and "nofork/noexec" plans

[Rob Landley]

On Monday 13 March 2006 2:24 am, Denis Vlasenko wrote:
> On Friday 10 March 2006 22:01, Rob Landley wrote:
> > > We can even have both:
> >
> > If X can replace Y then you don't need both.  If you need both, it's
> > because X can't really replace Y, which is a defect in X.
> >
> > > 	xlookup_host(&s_in, argv[optind]); //Will die with default error msg
> > >
> > > 	lookup_host_or_die(&s_in, argv[optind], "\0x3" "Custom error message
> > > and exit code"); --
> >
> > Having both is bigger.  The error message string is generally the biggest
> > part.  Moving the test out of line but then supply an extra argument on
> > the stack is not a big win.
>
> Sometimes you want custom error message. patch.c:
>
>         if (fputs(line, dest_stream) == EOF) {
>                 bb_perror_msg_and_die("Error writing to new file");
>         }

At some point, we may face the spectre of translating our error messages.  
Dunno.  Some of the earliest code uses libbb/messages.c, although that's 
fallen out of use.  I'm holding off on worrying about the whole issue for 
right now...

> We cannot save here on error message.
>
>         xfputs(line, dest_stream);
>
> can give "Write error" at most.
> No "Error writing to new file" or "Error writing to '%s'", filename.
>
>         fputs_or_die(line, dest_stream, "new file");
>
> won't save that much, but it will save something AND will provide
> meaningful error message.
>
> Why call it fputs_or_die instead of xfputs, then? I think that almost
> all currently existing xfuncs have exactly the same parameters as
> corresponding C lib funcs:
>
> 	void* malloc(size_t sz);
> 	void* xmalloc(size_t sz /* no extra params! */ );
>
> And I like this. Thus:
>
>         xfputs(line, dest_stream, "new file");	/* breaks that rule */
>         fputs_or_die(line, dest_stream, "new file"); /* I think this is
> better */

It makes a certain amount of sense.  Hmmm...

An if() vs an extra parameter is probably a wash.  An if() plus a function 
call with one parameter, vs an extra parameter, is probably a win, but not 
much of one.  It needs a number of uses before the overhead of the extra 
function gets overtaken, and it's a small enough gain that advances in 
compiler optimization could swamp it, and I'm not sure it's worth the extra 
learning curve...

I could be convinced, but right now I've got my hands full trying to focus on 
getting this darn mount.c checked in (it's working for the simple tests), and 
then make passwd.c use salt, then a 1.1.1-rc1 and a few days of "ok 
everybody, try it out" before annointing it 1.1.1.

I have a test infrastructure that tests commands that require root access.  
Wheee...

Rob
-- 
Never bet against the cheap plastic solution.