bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] inttostr.h: add compile-time buffer overrun checks


From: Paul Eggert
Subject: Re: [PATCH] inttostr.h: add compile-time buffer overrun checks
Date: Mon, 25 Oct 2010 10:58:27 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.14) Gecko/20101006 Thunderbird/3.0.9

On 10/25/10 03:09, Paolo Bonzini wrote:

> Maybe this could use "func (n, alloca (INT_BUFSIZE_BOUND (t)))" if C99
> is not in use? 

No, alas, because on some hosts, alloca cannot be used within an
argument to a call.  This is because alloca messes with the stack
pointer at the same time that the compiler is pushing things onto the
stack.  This is documented in gnulib's lib/alloca.in.h.

However, the code could fall back on malloc (INT_BUFSIZE_BOUND (t)).
Although that would be a memory leak, in some applications (GNU tar,
say?) this would be an acceptable fallback, so perhaps gnulib should
do that.  Applications for which this is not an acceptable fallback,
and which do not want to assume C99, would therefore be asked to not
use int2str etc.

For C89 compilers, possibly we could detect at compile time whether
it's safe to call alloca from within a function's argument.  (Is this
safe in GCC?  I briefly checked the doc and could not find the answer.
If it is safe, that would catch many of our uses.)  This would make
for fewer memory leaks on these older systems.  I'm leery of
doing this for non-GCC compilers, though, as they're notoriously
buggy in this area.

On 10/25/10 02:27, Bruno Haible wrote:
>
> If we go this route, then I'd be in favour of letting gnulib-tool check
> that, by default, it does not include code that assumes C99. This means:
>   - Modules should have an optional attribute "requires-c99",
>  ...

That sounds useful, but the proposed change is to some extent an
exceptional case, as the proposed inttostr module is just as useful as
before for code that does not want to assume C99, and so a
"requires-c99" attribute would be misleading.

Perhaps this could be addressed by putting the new macros into a new
int2str module that does assume C99.

However, if we include the workarounds discussed above, the int2str
code would run on C89 hosts (albeit with memory leaks), which would
mean it would not fall neatly into the "requires-c99" camp, even if
this code is in a new, separate module.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]