Hi Jim,
> Bruno's comment (in the text you elided) suggests intent to have
> pathmax.h leave PATH_MAX undefined on the Hurd:
>
> >> I find it reasonable to use "#ifdef PATH_MAX" in front of every use of
> >> PATH_MAX, like POSIX requires.
>
> With such a change, each of the above uses would
On 06/23/2011 03:02 AM, Jim Meyering wrote:
> but that would require a different diagnostic, since there
> is no "array" involved, so it may be better to leave that for
> a separate stack-size-related test.
-Wframe-larger-than=4096 might be a useful entry to add to the
manywarnings module.
--
Er
On 06/23/2011 03:02 AM, Jim Meyering wrote:
> Eric Blake wrote:
>> POSIX allows PATH_MAX to be undefined. And even if you use the
>> gnulib pathmax module, where "pathmax.h" guarantees a definition,
>> the definition might not be constant or might be so large as to
>> be wasteful or cause stack ov
On 06/23/2011 06:34 AM, Jim Meyering wrote:
>> +# not be constant, or might overflow a stack. In general, use PATH_MAX as
>> +# a limit, not an array or alloca size.
>> +sc_prohibit_path_max_allocation:
>> +@prohibit='(\balloca *\([^)]*|\[[^]]*)PATH_MAX' \
>> +halt='Avoid a
Eric Blake wrote:
> On 06/23/2011 03:02 AM, Jim Meyering wrote:
>> Eric Blake wrote:
>>> POSIX allows PATH_MAX to be undefined. And even if you use the
>>> gnulib pathmax module, where "pathmax.h" guarantees a definition,
>>> the definition might not be constant or might be so large as to
>>> be w
Eric Blake wrote:
> POSIX allows PATH_MAX to be undefined. And even if you use the
> gnulib pathmax module, where "pathmax.h" guarantees a definition,
> the definition might not be constant or might be so large as to
> be wasteful or cause stack overflows. PATH_MAX should only be
> used as a limi
