On 06/30/2016 06:01 AM, Aldy Hernandez wrote:
On 06/18/2016 07:55 PM, Martin Sebor wrote:
On 06/16/2016 02:32 AM, Aldy Hernandez wrote:
p.s. The pass currently warns on all uses of VLAs. I'm not completely
sold on this idea, so perhaps we could remove it, or gate it with a
flag.
I also thi
On 06/18/2016 07:55 PM, Martin Sebor wrote:
On 06/16/2016 02:32 AM, Aldy Hernandez wrote:
p.s. The pass currently warns on all uses of VLAs. I'm not completely
sold on this idea, so perhaps we could remove it, or gate it with a flag.
I also think that VLA diagnostics would be better control
On 21/06/16 17:52, Martin Sebor wrote:
> On 06/21/2016 10:00 AM, Jakub Jelinek wrote:
>> On Tue, Jun 21, 2016 at 09:57:59AM -0600, Jeff Law wrote:
Would a new attribute to annotate async-signal safe functions
help? I envision that the attribute on a function definition
would turn of
On 06/28/2016 08:40 AM, Aldy Hernandez wrote:
Hi.
In addressing the issues that were brought up I ran into bounded allocas
that are bounded by an unknown size. Should we warn on these?:
if (n < SOME_GLOBAL)
alloca(n)
In my WIP I am warning with:
x.c:6:5: warning: alloca
Hi.
In addressing the issues that were brought up I ran into bounded allocas
that are bounded by an unknown size. Should we warn on these?:
if (n < SOME_GLOBAL)
alloca(n)
In my WIP I am warning with:
x.c:6:5: warning: alloca bound is unknown [-Walloca]
Though
On 06/21/2016 10:00 AM, Jakub Jelinek wrote:
On Tue, Jun 21, 2016 at 09:57:59AM -0600, Jeff Law wrote:
Would a new attribute to annotate async-signal safe functions
help? I envision that the attribute on a function definition
would turn off the alloca/VLA to malloc transformation, and
could als
On Tue, Jun 21, 2016 at 09:57:59AM -0600, Jeff Law wrote:
> >Would a new attribute to annotate async-signal safe functions
> >help? I envision that the attribute on a function definition
> >would turn off the alloca/VLA to malloc transformation, and
> >could also diagnose calls to other function w
On 06/21/2016 09:51 AM, Martin Sebor wrote:
On 06/20/2016 03:41 PM, Jeff Law wrote:
On 06/20/2016 08:56 AM, Joseph Myers wrote:
On Sat, 18 Jun 2016, Martin Sebor wrote:
the function regardless of the value of its argument). At
the same time, it seems that an even more reliable solution
than
On 06/20/2016 03:41 PM, Jeff Law wrote:
On 06/20/2016 08:56 AM, Joseph Myers wrote:
On Sat, 18 Jun 2016, Martin Sebor wrote:
the function regardless of the value of its argument). At
the same time, it seems that an even more reliable solution
than pointing out potentially unsafe calls to the
On 06/18/2016 05:55 PM, Martin Sebor wrote:
I think detecting potentially problematic uses of alloca would
be useful, especially when done in an intelligent way like in
your patch (as opposed to simply diagnosing every call to
the function regardless of the value of its argument). At
the same
On 06/20/2016 08:56 AM, Joseph Myers wrote:
On Sat, 18 Jun 2016, Martin Sebor wrote:
the function regardless of the value of its argument). At
the same time, it seems that an even more reliable solution
than pointing out potentially unsafe calls to the function
and relying on users to modify t
On Sat, 18 Jun 2016, Martin Sebor wrote:
> the function regardless of the value of its argument). At
> the same time, it seems that an even more reliable solution
> than pointing out potentially unsafe calls to the function
> and relying on users to modify their code to use malloc for
> large/unb
On 06/16/2016 02:32 AM, Aldy Hernandez wrote:
Hi folks!
I've been working on a plugin to warn on unbounded uses of alloca() to
help find questionable uses in glibc and other libraries. It occurred
to me that the broader community could benefit from it, as it has found
quite a few interesting ca
On 06/16/2016 02:32 AM, Aldy Hernandez wrote:
Hi folks!
I've been working on a plugin to warn on unbounded uses of alloca() to
help find questionable uses in glibc and other libraries. It occurred
to me that the broader community could benefit from it, as it has found
quite a few interesting ca
On Thu, Jun 16, 2016 at 04:32:57AM -0400, Aldy Hernandez wrote:
> p.s. The pass currently warns on all uses of VLAs. I'm not completely sold
> on this idea, so perhaps we could remove it, or gate it with a flag.
Just random nits, no comments on the idea of the patch.
> * walloca.c: New pas
Hi folks!
I've been working on a plugin to warn on unbounded uses of alloca() to
help find questionable uses in glibc and other libraries. It occurred
to me that the broader community could benefit from it, as it has found
quite a few interesting cases. So, I've reimplemented it as an actual
16 matches
Mail list logo
