https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
--- Comment #30 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:b825a22890740f341eae566af27e18e528cd29a7
commit r11-959-gb825a22890740f341eae566af27e18e528cd29a7
Author: Martin Sebor
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Last reconfirmed|2008-03-30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
Bug 10138 depends on bug 33086, which changed state.
Bug 33086 Summary: warn for read-only uninitialized variables passed as
arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33086
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
--- Comment #27 from Martin Sebor ---
*** Bug 33086 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
--- Comment #26 from Martin Sebor ---
It seems that it should be possible to enhance the warn_uninitialized_vars
function in tree-ssa-uninit.c to detect this case by iterating over a callee's
arguments and warn on uninitialized variables whose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
Manuel López-Ibáñez changed:
What|Removed |Added
CC||developm...@faf-ltd.com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
Bug 10138 depends on bug 27120, which changed state.
Bug 27120 Summary: Should warn about uninitialized use of variable array element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27120
What|Removed |Added
--- Comment #23 from matt at use dot net 2009-12-31 01:44 ---
I just ran into a bug that this feature would have found for me at
compile-time. Instead, it required exercising the code under valgrind, which
took quite some time. If voting were enabled, I would vote for this bug.
--
--- Comment #10 from manu at gcc dot gnu dot org 2007-08-20 14:49 ---
I now think that Andrew is right and that PR33086 and this one are INVALID.
'const' does not mean read-only in C++ at all, and much less in C. atoi(const
char *) could always initialize buf[]. However, perhaps it can
--- Comment #11 from bangerth at dealii dot org 2007-08-20 14:56 ---
(In reply to comment #10)
I now think that Andrew is right and that PR33086 and this one are INVALID.
'const' does not mean read-only in C++ at all, and much less in C. atoi(const
char *) could always initialize
--- Comment #12 from manu at gcc dot gnu dot org 2007-08-20 15:03 ---
(In reply to comment #11)
(In reply to comment #10)
I now think that Andrew is right and that PR33086 and this one are INVALID.
'const' does not mean read-only in C++ at all, and much less in C.
atoi(const
--- Comment #13 from manu at gcc dot gnu dot org 2007-08-20 15:08 ---
(In reply to comment #12)
This testcase has nothing to do with uninitialized variables. If the variable
is 'const' already, then there will never be a warning. Will it produce
segmentation fault for a local
--- Comment #14 from bangerth at dealii dot org 2007-08-20 15:54 ---
(In reply to comment #12)
This testcase has nothing to do with uninitialized variables.
No, of course. I only meant to reply to your assertion that there could be
cases where a function initializes an object that is
--- Comment #15 from manu at gcc dot gnu dot org 2007-08-20 16:15 ---
(In reply to comment #14)
This is meant to only counter your point that:
'const' does not mean read-only in C++ at all, and much less in C.
atoi(const
char *) could always initialize buf[].
This simply isn't
--- Comment #16 from bangerth at dealii dot org 2007-08-20 16:21 ---
(In reply to comment #15)
Of course, the output is '5' and not '0'. So yes, atoi() seems perfectly able
to initialize buf. (or perhaps, I am still confused).
I think you are. This program here segfaults:
--- Comment #17 from manu at gcc dot gnu dot org 2007-08-20 16:44 ---
(In reply to comment #16)
(In reply to comment #15)
Of course, the output is '5' and not '0'. So yes, atoi() seems perfectly
able
to initialize buf. (or perhaps, I am still confused).
Since use() (like
--- Comment #18 from manu at gcc dot gnu dot org 2007-08-20 16:46 ---
When I say constant are not propagated I mean the constant value of a
variable such as:
int i=0;
use(i);
foo(i);
Here, GCC does not propagate the value of i to do foo(0). Remove the call to
use and then it
--- Comment #19 from bangerth at dealii dot org 2007-08-20 16:58 ---
(In reply to comment #18)
When I say constant are not propagated I mean the constant value of a
variable such as:
int i=0;
use(i);
foo(i);
Here, GCC does not propagate the value of i to do foo(0).
--- Comment #20 from manu at gcc dot gnu dot org 2007-08-20 17:12 ---
(In reply to comment #19)
What if you had const int i=0? As I said before, use() may do a const-cast
to get rid of the constness of its argument, but the result is only
well-defined
if the object pointed to is
--- Comment #21 from gdr at cs dot tamu dot edu 2007-08-20 18:50 ---
Subject: Re: warn for uninitialized arrays passed as const* arguments
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| When I say constant are not propagated I mean the constant value of a
| variable such as:
--- Comment #22 from h dot b dot furuseth at usit dot uio dot no
2007-08-20 22:45 ---
Subject: Re: warn for uninitialized arrays passed as const* arguments
manu at gcc dot gnu dot org writes:
But it seems that the current policy of GCC is to not assume that such
functions actually
--- Comment #9 from manu at gcc dot gnu dot org 2007-08-16 10:57 ---
Let's simplify this report. This one is now about
int atoi(const char *);
int foo()
{
char buf[10];
return atoi(buf);
}
As comment #3 mentions, this is a combination of
1) Report use of uninitialized array
25 matches
Mail list logo
