[Toybox] [PATCH] xwrap: implement xputs() like xputc().

[Rob Landley]

On 1/22/24 17:56, enh via Toybox wrote:
> Obviously I could have gone the other direction and made xputc() use
> xferror() like xputs() did, but given that xferror() is only used in vi,
> and not obviously meaningful there, I'm assuming that xferror() probably
> won't last...

On the one hand, I'd like to avoid lots of different error_exit("write") calls
with slightly different strings. On the other, the return code is RIGHT THERE
and checking it is almost free...

xexit() has its own redundant error handling because it's a warning instead of
an exit (since it's already exiting and it's silly to recurse. (I mean it should
be mostly safe to recurse, modulo marginal nommu stack size, and I made sure
xexit() does a llist_pop() to remove each atexit() call from the list before
calling it, but that was for the nofork longjmp() users. But unnecessary
recursing there is just ugly.) Also, technically it does fflush(0) instead of
just stdout, meaning if any OTHER FILE * had pending output that didn't go out,
the exit path should also notice and go "hey"...

But right now xferror(), xprintf(), xputsl(), xputc(), and xwrite() all have
uncomfortably similar error handling copied into them.

xprintf() has no excuse, xputsl() actually does a flush, xputc() is checking a
return code that's right there, and xwrite() is to fd not FILE.

Grrr. One of those "the fighting is so vicious because the stakes are so small"
things where it itches but no approach is heavy enough to obvious tip the scales...

> Also remove an obsolete comment that applied to xflush() but not
> xferror().

Thanks, missed that.

Commit 5a4c35342642, I went with "consistently use xferror()".

Rob