Wednesday May 23, 2007

Sun Studio 12 - simplifying the debugging process


The feature discussed here is in an early form and available only through the use of a special compiler switch. The functionality isIn addition, since uninitialized local variable values are no longer random, whatever errors are seen should be not yet fully supported, but any feedback on the utility (or lack of utility :-) will help determine whether it is ever turned into a first-class, fully supported option in an upcoming update/patch. Feel free to comment directly to me or comment via SDN (Sun Developer Network) C and C++ compiler forums. Become a member and let us know what you think.


Debugging is an integral part of program development. A common bug, which can be one of the most difficult to detect due to its often random behavior, is that of using uninitialized local variables. Errors caused by these uninitialized variables can range from wrong answers to erratic program behavior resulting in segmentation faults.

Various tools, such as Purify, are helpful in detecting these kinds of programming errors. However, for large applications, these tools can sometimes be cumbersome. If there were a method to assist the programmer in detecting these errors, implemented in the compiler as an option, it would simplify the debugging process.

To that end, as an aid to programmers using the Sun Studio C compiler (and also the C++ compiler), a new flag has been added. This new flag instructs the compiler to assign pre-defined "garbage" values, based on data type, to all local variables. The expectation is that any subsequent use of a local variable prior to a "real" assignment will cause some form of an obvious error condition closer, in terms of program flow, to the actual cause of the problem (the use of an uninitialized variable) than would have otherwise been the case with the typical random value.

If this sounds somewhat familiar to any who have used Sun Studio tools in the past, it should. Since version 7.1, Sun Studio Fortran has supported the -xcheck flag, which is syntactically described as:


and is documented to:

"Perform special initialization of local variables."

"The compiler initializes local variables to a value that is likely to cause an arithmetic exception if it is used by the program before it is assigned. Memory allocated by the ALLOCATE statement will also be initialized in this manner."

"Module variables, SAVE variables, and variables in COMMON blocks are not initialized."

It is this flag that has been added to C and C++, and it's available on all architectures. The only significant difference between Fortran and C/C++ is in the excluded initializations: C/C++ exclude globals and statics.

As alluded to earlier, for the upcoming initial release of Sun Studio 12, this feature is only available by using a special switch. In other words, it is not possible to simply specify


This will result in the nifty little error message:

cc: Warning: illegal option -xcheck=init_local
usage: cc [ options] files. Use 'cc -flags' for details

The special switch that must be used to access this new flag is defined in two different ways, depending upon which compiler is used. For C, the switch is -W0. For C++, the switch is -Qoption. These can be used as follows to access the new init_local feature:

For C


For C++

-Qoption ccfe -xcheck=init_local

Note that the specific values used for initializations are always subject to change and can't be relied upon to remain identical between releases. Also, note that by the very nature of what -xcheck=init_local does, memory debuggers most likely will not be able to detect uses of uninitialized local variables in code compiled with this flag.

Friday May 11, 2007

Sun Studio 11 and a video game ... of course they go together

Ok, so I jump on over to Roman's blog entry

What do I see? Two things of which I've been guilty (hmm, perhaps I shouldn't be admitting any of this). First, I am a fan of video games, and not just when I was younger (I won't date myself by admitting to which early game console I owned). My most recent stint in the gaming world came from Halo/Halo2, though I've layed off the carnage for the time being (wait 'til November, though ... then it's Halo 3 ... whoot! whoot!)

I've also been the creater - though it's been many, many years now, and several companies ago - of some code a co-worker of mine took great pleasure in teasing me about. I dare not even bring it up to this day for fear of mass embarrassment. Besides, I'd deny it anyway.

Ok, so I've bared my soul - so to speak. What does any of this have to do with Sun Studio? Well, the main point of all this was, as noted in Roman's blog, the creation of this

a nifty little game that just happens to involve Sun Studio 11. Now, Halo it ain't. But, it's still quite a bit of fun.

Dave-Bob says, "Check it out".




« September 2016