Am Wed, Oct 05, 2022 at 12:06:10PM + schrieb nia:
> On Tue, Oct 04, 2022 at 12:21:08AM +0200, Joerg Sonnenberger wrote:
> > On Mon, Oct 03, 2022 at 12:31:42PM +, nia wrote:
> > > I'd argue that providing alloca(3) as anything except a compiler
> > > builtin is a bug, and that kind of thing
On Tue, Oct 04, 2022 at 02:22:23AM +, David Holland wrote:
> On Tue, Oct 04, 2022 at 12:41:07AM +0300, Valery Ushakov wrote:
> > On Mon, Oct 03, 2022 at 18:32:47 +, David Holland wrote:
> >
> > > On Mon, Oct 03, 2022 at 03:45:06PM +0200, Roland Illig wrote:
> > > > > This is the
On Wed, Oct 05, 2022 at 12:06:10 +, nia wrote:
> On Tue, Oct 04, 2022 at 12:21:08AM +0200, Joerg Sonnenberger wrote:
> > On Mon, Oct 03, 2022 at 12:31:42PM +, nia wrote:
> > > I'd argue that providing alloca(3) as anything except a compiler
> > > builtin is a bug, and that kind of thing
On Tue, Oct 04, 2022 at 12:21:08AM +0200, Joerg Sonnenberger wrote:
> On Mon, Oct 03, 2022 at 12:31:42PM +, nia wrote:
> > I'd argue that providing alloca(3) as anything except a compiler
> > builtin is a bug, and that kind of thing should never be used.
>
> Well, if you are in strict C/C++
On Tue, Oct 04, 2022 at 12:41:07AM +0300, Valery Ushakov wrote:
> On Mon, Oct 03, 2022 at 18:32:47 +, David Holland wrote:
>
> > On Mon, Oct 03, 2022 at 03:45:06PM +0200, Roland Illig wrote:
> > > > This is the current alloca definition in the libc headers:
> > > >
> > > > #if
On Mon, Oct 03, 2022 at 12:31:42PM +, nia wrote:
> I'd argue that providing alloca(3) as anything except a compiler
> builtin is a bug, and that kind of thing should never be used.
Well, if you are in strict C/C++ standard mode, alloca should not exist
because it is not part of the standard.
On Mon, Oct 03, 2022 at 18:32:47 +, David Holland wrote:
> On Mon, Oct 03, 2022 at 03:45:06PM +0200, Roland Illig wrote:
> > > This is the current alloca definition in the libc headers:
> > >
> > > #if defined(_NETBSD_SOURCE)
> > > #if defined(alloca) && (alloca == __builtin_alloca) && \
> If you would like to contribute to an effort to fumigate pkgsrc for
> alloca uses, please go ahead. [...] However, iirc you won't touch
> pkgsrc for some reason :-p
Not so much "won't" has "have no reason to". pkgsrc, at least last I
checked, makes no attempt to be useful to me, to support
On Mon, Oct 03, 2022 at 02:20:20PM -0400, Mouse wrote:
> >>> #if defined(_NETBSD_SOURCE)
> >>> #if defined(alloca) && (alloca == __builtin_alloca) && \
> >> [...]
> > _NETBSD_SOURCE and __builtin_alloca are each in reserved-for-any-use
> > namespace, so there are no grounds for citing the
On Mon, Oct 03, 2022 at 03:45:06PM +0200, Roland Illig wrote:
> > This is the current alloca definition in the libc headers:
> >
> > #if defined(_NETBSD_SOURCE)
> > #if defined(alloca) && (alloca == __builtin_alloca) && \
>
> According to my knowledge of the C preprocessor, the condition
>>> #if defined(_NETBSD_SOURCE)
>>> #if defined(alloca) && (alloca == __builtin_alloca) && \
>> [...]
> _NETBSD_SOURCE and __builtin_alloca are each in reserved-for-any-use
> namespace, so there are no grounds for citing the standard as basis
> for any behaviour whatsoever from that.
I think I
On Mon, Oct 03, 2022 at 09:33:47AM -0400, Mouse wrote:
> >>> I'd argue that providing alloca(3) as anything except a compiler
> >>> builtin is a bug, and that kind of thing should never be used.
> >> I'd argue that alloca should never be used and actually should never
> >> have existed. As
>> #if defined(_NETBSD_SOURCE)
>> #if defined(alloca) && (alloca == __builtin_alloca) && \
> According to my knowledge of the C preprocessor, the condition
> 'alloca == __builtin_alloca' always evaluates to '0 == 0', assuming
> that if 'alloca' and '__builtin_alloca' are actually defined, they
>
Am 03.10.2022 um 14:31 schrieb nia:
This is the current alloca definition in the libc headers:
#if defined(_NETBSD_SOURCE)
#if defined(alloca) && (alloca == __builtin_alloca) && \
According to my knowledge of the C preprocessor, the condition 'alloca
== __builtin_alloca' always evaluates to
>>> I'd argue that providing alloca(3) as anything except a compiler
>>> builtin is a bug, and that kind of thing should never be used.
>> I'd argue that alloca should never be used and actually should never
>> have existed. As far as I can see it does nothing that can't be
>> done better - more
On Mon, Oct 03, 2022 at 08:45:33AM -0400, Mouse wrote:
> > I'd argue that providing alloca(3) as anything except a compiler
> > builtin is a bug, and that kind of thing should never be used.
>
> I'd argue that alloca should never be used and actually should never
> have existed. As far as I can
> I'd argue that providing alloca(3) as anything except a compiler
> builtin is a bug, and that kind of thing should never be used.
I'd argue that alloca should never be used and actually should never
have existed. As far as I can see it does nothing that can't be done
better - more portably and
On Mon, Oct 03, 2022 at 12:31:42PM +, nia wrote:
> Is there any reason we don't simplify this in the headers -
> __builtin_alloca(size) seems to work with every compiler?
I forgot to add: __builtin_alloca works with -std=c99,
with GCC and clang.
This TODO item has been in libc's shlib_version file for ages:
"remove alloca fallback and expect compiler to provide a builtin version."
On various architectures (powerpc, aarch64), pkgsrc bulk build reports
are filled with the following error:
"undefined reference to `alloca'"
On other
19 matches
Mail list logo
