On Fri, Dec 02, 2016 at 11:13:29AM -0700, Jeff Law wrote:
> >But -Wuninitialized also found tons of real-world bugs. Do we have a single
> >real-world example where such a warning would actually be useful (as in,
> >there would be an actual bug)? Otherwise we are adding workarounds for a
> >warni
On 12/02/2016 11:11 AM, Jakub Jelinek wrote:
On Fri, Dec 02, 2016 at 11:02:33AM -0700, Jeff Law wrote:
It won't cause any problems in this and probably most instances, but leaving
the code in its prior state is simply wrong from a maintenance standpoint.
I'd much rather have the code explicitly
On Fri, Dec 02, 2016 at 11:02:33AM -0700, Jeff Law wrote:
> It won't cause any problems in this and probably most instances, but leaving
> the code in its prior state is simply wrong from a maintenance standpoint.
>
> I'd much rather have the code explicitly and safely handle the zero operands
> c
On 12/02/2016 10:58 AM, Jakub Jelinek wrote:
On Thu, Dec 01, 2016 at 11:43:19PM -0700, Jeff Law wrote:
Martin's alloca work flagged this code as problematical. Essentially if we
had a statement with no operands and the statement was not in the hash
table, then we could end up performing alloca
On Thu, Dec 01, 2016 at 11:43:19PM -0700, Jeff Law wrote:
>
> Martin's alloca work flagged this code as problematical. Essentially if we
> had a statement with no operands and the statement was not in the hash
> table, then we could end up performing alloca (0), which is inadvisable.
I still don
Martin's alloca work flagged this code as problematical. Essentially if
we had a statement with no operands and the statement was not in the
hash table, then we could end up performing alloca (0), which is
inadvisable.
We can safely just avoid the whole block of code if there are no
operan
