On Wed, May 19, 2021 at 08:58:42PM +0200, Joerg Sonnenberger wrote:
> On Wed, May 19, 2021 at 09:56:23AM +, nia wrote:
> > The current situation in pkgsrc (where lots of software using alloca
> > needs to be BUILDLINK_TRANSFORMED to use the -std=gnu... variant, or
> > is patched to use the buil
On Wed, May 19, 2021 at 09:56:23AM +, nia wrote:
> The current situation in pkgsrc (where lots of software using alloca
> needs to be BUILDLINK_TRANSFORMED to use the -std=gnu... variant, or
> is patched to use the builtin directly) is not really one I'm happy
> with.
For most software it is e
> If some software expects an but the base OS does not
> provide it, then is it more useful to have a devel/alloca package
> which can be buildlinked which would provide it?
I'm not sure whether that can be done even in principle. I don't
really understand alloca all that well, but my impression
On Wed, 19 May 2021, nia wrote:
> I think there's several points of view:
>
> 1) Everything using alloca() is broken (valid, it's a nasty function)
>
> 2) Everything using extensions should properly declare it does so
>(using eg. -std=gnu99 and so on), and not use standards mode.
>
> 2) So
I think there's several points of view:
1) Everything using alloca() is broken (valid, it's a nasty function)
2) Everything using extensions should properly declare it does so
(using eg. -std=gnu99 and so on), and not use standards mode.
2) Software that makes certain assumptions about almos
In the commit message for the recent change to the builtin echo
in /bin/sh I said:
While here, conform to the POSIX requirement on echo (and many other
standard utilities, but definitely not all) that when the utility
does exit(>0) a message must be written to stderr ...
T
