implenting BB variations of standard system calls

[Denis Vlasenko]

On Wednesday 19 April 2006 21:47, Robert P. J. Day wrote:
> clearly, it does the same thing but that's entirely forgivable since
> it's meant to just be a simple extension of strncpy() and it would be
> silly to change the semantics.  but let's keep going and concentrate
> on the routines in bb_pwd.c.
> 
>   consider the BB-specific bb_getug() which calls safe_strncpy():
> 
> char * bb_getug(char *buffer, char *idname, long id, int bufsize, char
> prefix)
> {
>     if(bufsize > 0 ) {
>         assert(buffer!=NULL);
>         if(idname) {
>             return safe_strncpy(buffer, idname, bufsize);
>         }
>         snprintf(buffer, bufsize, "%ld", id);
>     } else if(bufsize < 0 && !idname) {
>         bb_error_msg_and_die("unknown %cid %ld", prefix, id);
>     }
>     return idname;
> }
> 
>   so bb_getug() has the same annoying design redundancy but, in *this*
> case, it's entirely unnecessary.

returning an int or pointer value requires _at most_ one insn in
the function body (on i386), sometimes even that is not needed,
because gcc will rearrange registers such that required value
ends up in eax register.

More to it, eax is clobbered by function call (even if you call void fn),
thus you save nothing in terms of register pressure on call site.

Thus you won't save much by removing "pointless" return value,
you will just annoy users who took liberty of using this feature.
They will need to do this:

-   newsurname = strcpy(names[i][surname_ofs+1], "Day");
+   newsurname = names[i][surname_ofs+1];
+   strcpy(newsurname, "Day");

You repay 3 bytes you saved inside strcpy in each call site
like one shown above.

> in short, i think there should be two general rules for writing
> internal BB routines.  1) if you're emulating a system call, try to
> keep the same semantics as much as possible, and 2) rewrite these
> silly routines that return nothing more than what they were passed in
> the first place, and use those return value for meaningful error
> codes.
> 
>   thoughts?

If you need more than one error code, it makes sense.
If there only one (or none) error condition possible,
returning NULL will work as good as returning integer error code.
--
vda