Re: critique of gnulib

[Paul Eggert]

Thanks for your thoughtful reply. A few points:

Jonas 'Sortie' Termansen wrote:

> I object to the notion that truncation is a worse outcome than a buffer
> overflow. A buffer overflow is at worst a remote code execution
> vulnerability, while a truncation is at worst a program bug (although
> that may be exploitable in turn, it is not inherently exploitable).

We look at things a different way. Buffer overflows are easily caught by 
widely-available tools, and if remote code execution is a problem then one ought 
to be using such tools. In contrast, silent truncation bugs cannot be caught 
easily and automatically, so these bugs are much harder to find and fix. If one 
looks at the overall bug burden, silent truncations are probably a worse problem 
for Gnulib-like code than buffer overflows are.  (Integer overflows are probably 
worse than either.)

Of course this is a judgment call and your judgment might differ. Still, there's 
a lot to say for the GNU tradition of refusing to impose arbitrary limits (as 
snprintf-using code usually does), and it's reasonable to follow that tradition.

> Generally asprintf should be used instead of
> sprintf/snprintf because it does the buffer allocation for you and
> significantly reduces the risk.

asprintf is often a good way to go, and Gnulib uses it. However, like sprintf 
and snprintf, asprintf mishandles large buffers and so careful code cannot use 
it to both allocate and format large results - which means that careful code 
must do the "risky" stuff anyway since asprintf is not up to the task.

> To recap, my primary requests are:
>
> 1) Categorizing gnulib into three parts (replacement functions for when
> they don't exist, workarounds for bugs, and utility functions).
>
> 2) Making it possible to disable the gnulib bug replacements with a
> configure command line option.
>
> 3) Defaulting to assume the best when cross-compiling to unknown systems.

(3) shouldn't be that hard to do, though it would be tedious. (2) sounds 
trickier, since not everybody agrees about what's a "bug" (are we talking about 
a bug relative to C11? to C99? to POSIX-2017? to current GNU? that sort of 
thing). I don't see the categories in (1) as being that sharp or useful, but 
perhaps I'm missing something.

To my mind, the most important feature needed is to make it easy to do reliable 
cross-compiling, by letting the builder supply a method for 'configure' to run a 
program on the target platform. This would be an Autoconf feature, not a Gnulib 
feature. It would have addressed many of your problems. It's been on the 
Autoconf to-do list nearly forever, alas.