Hi,
Quoting Agustina Arzille (2016-03-16 02:44:28)
> As promised, here's the patch to avoid the aforementioned alloca bugs.
> It's a bit of an overkill, imo, but it does support ridiculously long
> command-line arguments =D
It is way too complicated. We don't need to be efficient here.
Also,
I don't know where the notion expressed in the Linux man page came from.
I'm pretty sure it's never been true of GNU compilers. I don't think there
is any actual problem of the sort you have in mind with the existing code.
The generally issue of unbounded stack allocation is of course separate
As promised, here's the patch to avoid the aforementioned alloca bugs.
It's a bit of an overkill, imo, but it does support ridiculously long
command-line arguments =D
For most practical issues, the fix posted in
http://lists.gnu.org/archive/html/bug-hurd/2016-03/msg00086.html
should be enough.
Quoting Samuel Thibault (2016-03-15 18:30:16)
> Justus Winter, on Tue 15 Mar 2016 18:10:18 +0100, wrote:
> > Quoting Samuel Thibault (2016-03-15 17:31:53)
> > > Justus Winter, on Tue 15 Mar 2016 14:39:00 +0100, wrote:
> > > > Quoting Agustina Arzille (2016-03-15 14:11:27)
> > > > > Hello,
On 2016-03-15 15:02, Samuel Thibault wrote:
Agustina Arzille, on Tue 15 Mar 2016 14:57:19 -0300, wrote:
That's not what I meant. Stack overflow is clearly very unlikely, if
not
impossible. What I meant about 'dangerous' is the fact that alloca is
being
used inside the list of arguments of a
Agustina Arzille, on Tue 15 Mar 2016 14:57:19 -0300, wrote:
> On 2016-03-15 13:31, Samuel Thibault wrote:
> >Justus Winter, on Tue 15 Mar 2016 14:39:00 +0100, wrote:
> >>Quoting Agustina Arzille (2016-03-15 14:11:27)
> >>> Hello, everyone.
> >>>
> >>> I was browsing some gnumach source files, and
Hello, Samuel.
On 2016-03-15 13:31, Samuel Thibault wrote:
Justus Winter, on Tue 15 Mar 2016 14:39:00 +0100, wrote:
Quoting Agustina Arzille (2016-03-15 14:11:27)
> Hello, everyone.
>
> I was browsing some gnumach source files, and noticed some dangerous use
> of the gcc builtin 'alloca'. In
Justus Winter, on Tue 15 Mar 2016 18:10:18 +0100, wrote:
> Quoting Samuel Thibault (2016-03-15 17:31:53)
> > Justus Winter, on Tue 15 Mar 2016 14:39:00 +0100, wrote:
> > > Quoting Agustina Arzille (2016-03-15 14:11:27)
> > > > Hello, everyone.
> > > >
> > > > I was browsing some gnumach source
Quoting Samuel Thibault (2016-03-15 17:31:53)
> Justus Winter, on Tue 15 Mar 2016 14:39:00 +0100, wrote:
> > Quoting Agustina Arzille (2016-03-15 14:11:27)
> > > Hello, everyone.
> > >
> > > I was browsing some gnumach source files, and noticed some dangerous use
> > > of the gcc builtin
Justus Winter, on Tue 15 Mar 2016 14:39:00 +0100, wrote:
> Quoting Agustina Arzille (2016-03-15 14:11:27)
> > Hello, everyone.
> >
> > I was browsing some gnumach source files, and noticed some dangerous use
> > of the gcc builtin 'alloca'. In the file kern/bootstrap.c, lines 212 and
> > 228, we
Quoting Agustina Arzille (2016-03-15 15:44:13)
> > Good catch. However, alloca is dangerous even if used correctly, and
> > is best be avoided. Would you be so kind to prepare a patch to that
> > end?
> >
> > Thanks,
> > Justus
>
> Sure. I will cook up a patch when I get home. Right now, the
Hello, Justus,
On 2016-03-15 10:39, Justus Winter wrote:
Hi,
Quoting Agustina Arzille (2016-03-15 14:11:27)
Hello, everyone.
I was browsing some gnumach source files, and noticed some dangerous
use
of the gcc builtin 'alloca'. In the file kern/bootstrap.c, lines 212
and
228, we have the
Hi,
Quoting Agustina Arzille (2016-03-15 14:11:27)
> Hello, everyone.
>
> I was browsing some gnumach source files, and noticed some dangerous use
> of the gcc builtin 'alloca'. In the file kern/bootstrap.c, lines 212 and
> 228, we have the following statement:
>
> memcpy (alloca (len), ...)
Hello, everyone.
I was browsing some gnumach source files, and noticed some dangerous use
of the gcc builtin 'alloca'. In the file kern/bootstrap.c, lines 212 and
228, we have the following statement:
memcpy (alloca (len), ...)
This is dangerous because alloca works by adjusting the stack
14 matches
Mail list logo
