[bug-gnulib] Re: getdate don't need alloca

[Simon Josefsson]

Paul Eggert <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>
>> So could getdate depend on alloca-opt instead of alloca?
>
> Sorry, I don't understand how alloca-opt works.  Doesn't it invoke
> AC_FUNC_ALLOCA?  And doesn't that mean that the user must put
> $(ALLOCA) into ..._LIBADD?  And won't that break on hosts that don't
> have alloca?

Wouldn't it would work if the user didn't put $(ALLOCA) in LIBADD?

> Also, with alloca-opt, isn't a program supposed to inspect HAVE_ALLOCA
> before attempting to invoke alloca?  The Bison-generated code doesn't
> do that; instead, it inspects YYSTACK_USE_ALLOCA, defined (alloca),
> defined (_ALLOCA_H), and defined(__GNUC__) to decide whether to use
> alloca.  Since it includes <alloca.h>, _ALLOCA_H will be defined, so
> it will use alloca, even though alloca doesn't exist.

The Bison-generate code don't include alloca.h, getdate.y did.

Ok, given this I think there are three options:

1) leave things as they are. getdate will require alloca.

2) remove the dependency on alloca for getdate, and remove the
   '#include <alloca.h>' line in getdate.y. The Bison-generated code
   will automatically use malloc+free instead.

3) wrap the '#include <alloca.h>' inside a HAVE_ALLOCA test, in
   getdate.y.  Then if I'm not mistaken, getdate.y will work in all
   situations I can think of: no alloca stuff whatsoever, with
   alloca-opt, and with alloca.

   I agree with Bruno that it would pollute the *.c file with this #if
   check, but the reason is that the bison generated code test for the
   CPP symbol _ALLOCA_H which I think it shouldn't have done (there is
   no guarantee alloca.h declare that symbol).

I suspect 1) is the simplest option.

The reason for all this is that I was trying to avoid alloca, because
it is documented to crash if the code try to allocate a too large
buffer.  And I'm using getdate.y inside a library, which I wouldn't
want to crash because of this.  It is not clear to me if the
bison-generated code only ever allocate small strings -- to me it
seems it can grow the alloca buffer large.

Thanks,
Simon