C/C++ Option to Initialize Variables?
Hi All,
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
Is there an option to initialize variables to known values in a C/C++ program?
My use case is 'debug' builds and finding use of uninitialized values
that get lucky by being 0 most of the time. For example:
void DoSomeithWithFoo(FOO** ppf) {
if(ppf && *ppf == NULL) {
*ppf = new FOO;
...
}
}
FOO* p;
DoSomeithWithFoo(&p);
So I would like something that initializes to known, but non-NULL,
such as 0xCDCDCDCD or 0xFDFDFDFD (similar to Visual Studio behavior).
Jeff
Re: C/C++ Option to Initialize Variables?
On 18/02/13 11:40, Jeffrey Walton wrote:
Hi All,
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
Is there an option to initialize variables to known values in a C/C++ program?
My use case is 'debug' builds and finding use of uninitialized values
that get lucky by being 0 most of the time. For example:
void DoSomeithWithFoo(FOO** ppf) {
if(ppf && *ppf == NULL) {
*ppf = new FOO;
...
}
}
FOO* p;
DoSomeithWithFoo(&p);
So I would like something that initializes to known, but non-NULL,
such as 0xCDCDCDCD or 0xFDFDFDFD (similar to Visual Studio behavior).
Jeff
Probably not, put =0, if I say "int x;" I am just saying there is an
int, it's name is x, deal with it. I may assign to it later, sticking =0
at the end implicitly wouldn't be good for anything really.
However! calloc initializes the memory to zero change malloc(size to
calloc(1,size and you're done.
Does that help?
Alec
Re: C/C++ Option to Initialize Variables?
On 02/18/2013 02:02 PM, Alec Teal wrote:
On 18/02/13 11:40, Jeffrey Walton wrote:
Hi All,
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
Is there an option to initialize variables to known values in a C/C++
program?
My use case is 'debug' builds and finding use of uninitialized values
that get lucky by being 0 most of the time. For example:
void DoSomeithWithFoo(FOO** ppf) {
if(ppf && *ppf == NULL) {
*ppf = new FOO;
...
}
}
FOO* p;
DoSomeithWithFoo(&p);
So I would like something that initializes to known, but non-NULL,
such as 0xCDCDCDCD or 0xFDFDFDFD (similar to Visual Studio behavior).
Jeff
Probably not, put =0, if I say "int x;" I am just saying there is an
int, it's name is x, deal with it. I may assign to it later, sticking
=0 at the end implicitly wouldn't be good for anything really.
However! calloc initializes the memory to zero change malloc(size to
calloc(1,size and you're done.
Does that help?
Alec
I believe Jeff thinks the above is a bug in *his* code, and he wants a
flag to
help him spot it. By assigning non-NULL values to unintialized variables
will,
supposedly, make the code behave wrongly, making it easier to detect.
I agree that having gcc deliberately put garbage into uninitialized
variables can
be very helpful in shortening the compile-test-debug-fix loop. I run
valgrind only
occasionally, even though I run unit-tests after every modification.
This means
that bugs due to unintialized memory are sometimes detected many days after
they were first introduced, which makes it more difficult to understand the
bug. Testing code compiled with this flag will probably result in less
bugs of
this kind left to testing by valgrind.
I see the main issue with such flags in their interaction with tools like
valgrind. Such a flag could defeat valgrind's algorithm for detecting
unintialized local variables, unless it is made aware of the flag
(which I don't see how it could be done, without special hints from gcc).
Michael
Re: gcc : c++11 : full support : eta?
Gerald Pfeifer wrote, On Monday 18 February 2013 02:17 AM: On Thu, 24 Jan 2013, Richard Biener wrote: There are technical details of the maintaining part - like would the material reside in SVN? Or in the CVS where we keep our webpages? Or somewhere else public (github?)? Would we want to have an official maintainer and use the usual patch / review / approve mechanism for changes? Which raises the question of the format the courseware is in? Gerald? David? Whatever works for Uday and team, I'd say. With a strong recommendation to go for SVN since that is our primary tool for version control (and a stronger recommendation against CVS which I'd really love to migrate also the web pages away from). I am absolutely fine with SVN because that's what I use :-) However, we need some clarity on exactly what will go in SVN. We will have things like: * Text files such as html files (absolutely fine with SVN). * PDF slides (unsuitable for SVN because they are binary files). I don't mind uploading the LaTeX sources and associated Makefiles for creating pdf.However, we will need to test them out on a few machines that I have never touched to make sure that they don't depend on some local installations that I have stopped noticing. These slides do have some .epsi images that will also have to be added to the SVN repo. * Videos of lectures. I guess these are best kept in the form of links to our servers because we have high definition recordings (we will also make more space efficient videos) so a streaming option is best. So the most critical question is: Do we want to give LaTeX sources of slides or only the PDF files only. I am okay with both the options. Yeah, I know - the obvious link from the gcc.gnu.org page to click for a newcomer is 'contribute', but that page is awkward enough to scare off a possible contributor ;) True. Any ideas/suggestions? Happy to make changes... I'll try to come up with some concrete suggestions on how they can be reorganized. Uday.
Re: C/C++ Option to Initialize Variables?
On Mon, Feb 18, 2013 at 7:42 AM, Michael Veksler
wrote:
> On 02/18/2013 02:02 PM, Alec Teal wrote:
>>
>> On 18/02/13 11:40, Jeffrey Walton wrote:
>>>
>>> Hi All,
>>>
>>>
>>> http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
>>>
>>> Is there an option to initialize variables to known values in a C/C++
>>> program?
>>>
>>> My use case is 'debug' builds and finding use of uninitialized values
>>> that get lucky by being 0 most of the time. For example:
>>>
>>> void DoSomeithWithFoo(FOO** ppf) {
>>>if(ppf && *ppf == NULL) {
>>> *ppf = new FOO;
>>> ...
>>>}
>>> }
>>>
>>> FOO* p;
>>> DoSomeithWithFoo(&p);
>>>
>>> So I would like something that initializes to known, but non-NULL,
>>> such as 0xCDCDCDCD or 0xFDFDFDFD (similar to Visual Studio behavior).
>>>
>> ...
>>
>>
> I believe Jeff thinks the above is a bug in *his* code, and he wants a flag
> to
> help him spot it. By assigning non-NULL values to unintialized variables
> will,
> supposedly, make the code behave wrongly, making it easier to detect.
The reason I went looking for the flag is someone asked about a crash
on the OpenSSL mailing list. I knew it was due to an uninitialized
field (but they did not realize the value was not initialized). I
wanted to suggest a quick way to find what was not initialized.
How much code do you think would break because folks depend on getting
a 0 due to good graces or side effects (for example, the memory
manager returning a zeroized page)? What if the ".BSS" section was
initialized to 0xFF rather than a page full of NULLs?
> I agree that having gcc deliberately put garbage into uninitialized
> variables can
> be very helpful in shortening the compile-test-debug-fix loop. I run
> valgrind only
> occasionally, even though I run unit-tests after every modification. This
> means
> that bugs due to unintialized memory are sometimes detected many days after
> they were first introduced, which makes it more difficult to understand the
> bug. Testing code compiled with this flag will probably result in less bugs
> of
> this kind left to testing by valgrind.
Yes, it's a great feature of Visual Studio. It helps you find the
point of first failure (or the potential point) quickly.
> I see the main issue with such flags in their interaction with tools like
> valgrind. Such a flag could defeat valgrind's algorithm for detecting
> unintialized local variables, unless it is made aware of the flag
> (which I don't see how it could be done, without special hints from gcc).
When building for tools such as Valgrind, don't specify the flag ;)
Jeff
Re: C/C++ Option to Initialize Variables?
On 02/18/2013 03:28 PM, Jeffrey Walton wrote:
On Mon, Feb 18, 2013 at 7:42 AM, Michael Veksler
wrote:
On 02/18/2013 02:02 PM, Alec Teal wrote:
On 18/02/13 11:40, Jeffrey Walton wrote:
Hi All,
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
Is there an option to initialize variables to known values in a C/C++
program?
My use case is 'debug' builds and finding use of uninitialized values
that get lucky by being 0 most of the time. For example:
void DoSomeithWithFoo(FOO** ppf) {
if(ppf && *ppf == NULL) {
*ppf = new FOO;
...
}
}
FOO* p;
DoSomeithWithFoo(&p);
So I would like something that initializes to known, but non-NULL,
such as 0xCDCDCDCD or 0xFDFDFDFD (similar to Visual Studio behavior).
...
I believe Jeff thinks the above is a bug in *his* code, and he wants a flag
to
help him spot it. By assigning non-NULL values to unintialized variables
will,
supposedly, make the code behave wrongly, making it easier to detect.
The reason I went looking for the flag is someone asked about a crash
on the OpenSSL mailing list. I knew it was due to an uninitialized
field (but they did not realize the value was not initialized). I
wanted to suggest a quick way to find what was not initialized.
How much code do you think would break because folks depend on getting
a 0 due to good graces or side effects (for example, the memory
manager returning a zeroized page)? What if the ".BSS" section was
initialized to 0xFF rather than a page full of NULLs?
I agree that having gcc deliberately put garbage into uninitialized
variables can
be very helpful in shortening the compile-test-debug-fix loop. I run
valgrind only
occasionally, even though I run unit-tests after every modification. This
means
that bugs due to unintialized memory are sometimes detected many days after
they were first introduced, which makes it more difficult to understand the
bug. Testing code compiled with this flag will probably result in less bugs
of
this kind left to testing by valgrind.
Yes, it's a great feature of Visual Studio. It helps you find the
point of first failure (or the potential point) quickly.
I see the main issue with such flags in their interaction with tools like
valgrind. Such a flag could defeat valgrind's algorithm for detecting
unintialized local variables, unless it is made aware of the flag
(which I don't see how it could be done, without special hints from gcc).
When building for tools such as Valgrind, don't specify the flag ;)
I like when things just work, without weird dependencies. But the trade-off
sounds reasonable to me in this case, but I am not a GCC developer and
have no moral right to justify this claim.
Instead of joining your request for a new GCC feature I have a suggestion to
you. How about writing a plug-in for GCC to do that? I am no expert, but
writing a melt plug-in does not sound too complicated:
http://gcc-melt.org/
It is possible that you could add an initialization to every
uninitialized variable
in a simple melt plug-in.
I have never written a plug-in so I may be completely wrong, and it is not
that simple. I think that it is worth having a look.
Michael
Re: C/C++ Option to Initialize Variables?
On 18 February 2013 13:28, Jeffrey Walton wrote: > The reason I went looking for the flag is someone asked about a crash > on the OpenSSL mailing list. I knew it was due to an uninitialized > field (but they did not realize the value was not initialized). I > wanted to suggest a quick way to find what was not initialized. Valgrind. > How much code do you think would break because folks depend on getting > a 0 due to good graces or side effects (for example, the memory > manager returning a zeroized page)? It should break no valid programs. The invalid programs that break would benefit from an easily reproducable failure. > What if the ".BSS" section was > initialized to 0xFF rather than a page full of NULLs? That could break millions of perfectly valid programs, for no obvious benefit. > When building for tools such as Valgrind, don't specify the flag ;) You don't build for valgrind, it runs normal, uninstrumented binaries. That's one of its main advantages.
Re: C/C++ Option to Initialize Variables?
On Mon, Feb 18, 2013 at 9:43 AM, Jonathan Wakely wrote:
> On 18 February 2013 13:28, Jeffrey Walton wrote:
>> The reason I went looking for the flag is someone asked about a crash
>> on the OpenSSL mailing list. I knew it was due to an uninitialized
>> field (but they did not realize the value was not initialized). I
>> wanted to suggest a quick way to find what was not initialized.
>
> Valgrind.
That requires an additional package, and some developers don't use it.
>> How much code do you think would break because folks depend on getting
>> a 0 due to good graces or side effects (for example, the memory
>> manager returning a zeroized page)?
>
> It should break no valid programs. The invalid programs that break
> would benefit from an easily reproducable failure.
Right.
>> What if the ".BSS" section was
>> initialized to 0xFF rather than a page full of NULLs?
>
> That could break millions of perfectly valid programs, for no obvious benefit.
Its hypothetical, and could be a bit humorous. Why are developers
writing programs that rely upon undocumented features?
As crazy as it sound, it probably portable though. Are there any OS
link/loaders which use a memory manager that does not serve zeroized
pages (at least on the first run when drawing from a fresh pool)?
It not just userland. I've looked at lots of kernel code that relies
on the same good graces and luck. I'd love to see the effects of the
memory manager returning a page filed with HASH(counter).
>> When building for tools such as Valgrind, don't specify the flag ;)
>
> You don't build for valgrind, it runs normal, uninstrumented binaries.
> That's one of its main advantages.
Yes, agreed. The switch would *not* be specified for production code
('release' builds). But I'm talking about development ('debug'
builds).
Jeff
Re: C/C++ Option to Initialize Variables?
On 02/18/2013 03:07 PM, Jeffrey Walton wrote: > On Mon, Feb 18, 2013 at 9:43 AM, Jonathan Wakely > wrote: >> On 18 February 2013 13:28, Jeffrey Walton wrote: >>> What if the ".BSS" section was >>> initialized to 0xFF rather than a page full of NULLs? >> >> That could break millions of perfectly valid programs, for no obvious >> benefit. > Its hypothetical, and could be a bit humorous. Why are developers > writing programs that rely upon undocumented features? BSS being zero is certainly not an undocumented feature. Andrew.
Re: C/C++ Option to Initialize Variables?
On Mon, Feb 18, 2013 at 10:34 AM, Andrew Haley wrote: > On 02/18/2013 03:07 PM, Jeffrey Walton wrote: >> On Mon, Feb 18, 2013 at 9:43 AM, Jonathan Wakely >> wrote: >>> On 18 February 2013 13:28, Jeffrey Walton wrote: > What if the ".BSS" section was initialized to 0xFF rather than a page full of NULLs? >>> >>> That could break millions of perfectly valid programs, for no obvious >>> benefit. >> Its hypothetical, and could be a bit humorous. Why are developers >> writing programs that rely upon undocumented features? > > BSS being zero is certainly not an undocumented feature. C/C++ makes no assurances on the value of an unitialized variable, members, etc. DATA section is initialized data. BSS section is unitialized data. For statically allocated unitintialized object, it will go in BSS section. For uninitialized stack variable, it will go on the stack. Forgive me, but I don't see where anything is guaranteed to be zero'd before use. I'm likely wrong somewhere since you disagree. Jeff
Re: C/C++ Option to Initialize Variables?
On Monday 18 February 2013 09:44 PM, Jeffrey Walton wrote: On Mon, Feb 18, 2013 at 10:34 AM, Andrew Haley wrote: On 02/18/2013 03:07 PM, Jeffrey Walton wrote: On Mon, Feb 18, 2013 at 9:43 AM, Jonathan Wakely wrote: On 18 February 2013 13:28, Jeffrey Walton wrote: What if the ".BSS" section was initialized to 0xFF rather than a page full of NULLs? That could break millions of perfectly valid programs, for no obvious benefit. Its hypothetical, and could be a bit humorous. Why are developers writing programs that rely upon undocumented features? BSS being zero is certainly not an undocumented feature. C/C++ makes no assurances on the value of an unitialized variable, members, etc. DATA section is initialized data. BSS section is unitialized data. For statically allocated unitintialized object, it will go in BSS section. For uninitialized stack variable, it will go on the stack. Forgive me, but I don't see where anything is guaranteed to be zero'd before use. I'm likely wrong somewhere since you disagree. http://en.wikipedia.org/wiki/.bss Uday.
Re: C/C++ Option to Initialize Variables?
Hi, On Mon, 18 Feb 2013, Jeffrey Walton wrote: > On Mon, Feb 18, 2013 at 10:34 AM, Andrew Haley wrote: > > On 02/18/2013 03:07 PM, Jeffrey Walton wrote: > >> On Mon, Feb 18, 2013 at 9:43 AM, Jonathan Wakely > >> wrote: > >>> On 18 February 2013 13:28, Jeffrey Walton wrote: > > > What if the ".BSS" section was > initialized to 0xFF rather than a page full of NULLs? > >>> > >>> That could break millions of perfectly valid programs, for no obvious > >>> benefit. > >> Its hypothetical, and could be a bit humorous. Why are developers > >> writing programs that rely upon undocumented features? > > > > BSS being zero is certainly not an undocumented feature. > > C/C++ makes no assurances on the value of an unitialized variable, > members, etc. Wrong. It specifies that objects with static storage duration that aren't explicitely initialized are initialized with null pointers, or zeros depending on type. 6.7.8.10. Hence if .bss is to be used to place such objects then the runtime system _must_ make sure that it's zero initialized. IOW: it's only automatic and allocated variables that start with an indeterminate value when not initialized explicitely. Automatic variables, as they are on the stack, are unlikely to usually get the value 0 out of pure luck, so an option to initialize them to 0xDEADBEAF doesn't make much sense. And to initialize allocated variables with some bit pattern you can simply override malloc. So, this option seems to search for a problem it's supposed to help with. Ciao, Michael.
Re: C/C++ Option to Initialize Variables?
On Mon, 18 Feb 2013, Michael Matz wrote: > Automatic variables, as they are on the stack, are unlikely to usually get > the value 0 out of pure luck, so an option to initialize them to 0xDEADBEAF > doesn't make much sense. Hm, but the following comment from init-regs.c indicates that GCC will set some uninitialized vars to zero, except at -O0: /* Check all of the uses of pseudo variables. If any use that is MUST uninitialized, add a store of 0 immediately before it. For subregs, this makes combine happy. For full word regs, this makes other optimizations, like the register allocator and the reg-stack happy as well as papers over some problems on the arm and other processors where certain isa constraints cannot be handled by gcc. These are of the form where two operands to an insn my not be the same. The ra will only make them the same if they do not interfere, and this can only happen if one is not initialized. There is also the unfortunate consequence that this may mask some buggy programs where people forget to initialize stack variable. Any programmer with half a brain would look at the uninitialized variable warnings. */ However this seems to not touch variables with only may-uninitialized accesses. > And to initialize allocated variables with some bit pattern you can simply > override malloc. Or use MALLOC_PERTURB_ environment variable. -- Alexander
Re: C/C++ Option to Initialize Variables?
Forgive me, but I don't see where anything is guaranteed to be zero'd before use. I'm likely wrong somewhere since you disagree. http://en.wikipedia.org/wiki/.bss This is about what happens to work, and specifically notes that it is not part of the C standard. There is a big difference between programs that obey the standard, and those that don't but happen to work on some systems. The latter programs have latent bugs that can definitely cause trouble. A properly written C program should avoid uninitialized variables, just as a properly written Ada program should avoid them. In GNAT, we have found the Initialize_Scalars pragma to be very useful in finding uninitialized variables. It causes all scalars to be initialized using a specified bit pattern that can be specified at link time, and modified at run-time. If you run a program with different patterns, it should give the same result, if it does not, you have an uninitialized variable or other non-standard aspect in your program which should be tracked down and fixed. Note that the BSS-is-always-zero guarantee often does not apply when embedded programs are restarted, so it is by no means a universal guarantee.
Re: C/C++ Option to Initialize Variables?
Wrong. It specifies that objects with static storage duration that aren't explicitely initialized are initialized with null pointers, or zeros depending on type. 6.7.8.10. OK, that means that the comments of my last mesage don't apply to variables of this type. So they should at least optionally be excluded from any feature to initialize variables Hence if .bss is to be used to place such objects then the runtime system _must_ make sure that it's zero initialized.
Re: make_decl_one_only and inlining
Jan Hubicka ucw.cz> writes: > > > > How does the C++ frontend handle this? > > See logic in cgraph_function_body_availability. When function is weak (that is effect > of make_decl_one_only) it will be inlinable only if it is declared inline. This happens > to be the case of C++ weaks because of the implicit inline scheme. That's interesting. D has nothing similar to inline functions but it should be fine to mark all functions as DECL_DECLARED_INLINE_P. > > I suppose we need a flag on DECL saying that declaration is overwritable but > all copies of the functions must be semantically equivalent per ABI > specification. In that case the function should return AVAIABLE same way as > it > is doing for DECL_EXTERNAL stuff already. Isn't that basically the same as DECL_ONE_ONLY?
