Re: [Gnu-arch-users] Emgergency release of tla-1.2.1pre1

[Miles Bader]

On Sun, Apr 18, 2004 at 07:47:51AM -0700, Tom Lord wrote:
>     > I think that's a dangerous interface: as it stores up to `n + 1'
>     > characters, it requires the user to worry about subtracting one from
>     > their buffer size.  Sometimes they will forget to do this and just
>     > pass in `sizeof buf' or something.
> 
>     > It would be better to copy only `n - 1' real characters in the case
>     > of an overflow, so that the final `\0' makes `n'.
> 
> That just shifts around the bugs and resulting exploits.

If there are `exploits' that rely on a string being truncated, they'll
surface regardless of which interface str_cpy_n uses (as it doesn't change
the length of callers' fixed buffers) -- but the `stores up to n + 1 chars'
interface creates an _additional_ class of common bugs where the user passes
in `sizeof BUF' and ends up overwriting the character following BUF with 0.

The problem is that the size of a buffer is the common piece of info a caller
has, and the interface which is going to cause the least problems is the one
where they can just use that directly (not to mention avoiding the code
ugliness where 95% of the calls to str_cpy_n have `... - 1' as their last
argument).

> That's one reason why higher-level string types are being
> added to hackerlab.

That's of course a good thing.  I have noticed in what hacking I've done on
tla that string handling is usually pretty painless -- is this interface you
mean, or is there an even newer one?

Thanks,

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."