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 curre
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 sh
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++ st
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 define
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. I
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 Ne
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 stan
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 'a
>>> #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 ove
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 far
>> #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
> e
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 '0
>>> 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 p
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 s
> 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.
18 matches
Mail list logo
