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.
