Classical unitialized C pointer
-
While porting an old DOS software to Windows that controls a temperature bath, i came across this code to show error messages:
COUNT showerr(COUNT res)
{
char *szGp;
...
sprintf(szGp,"ibsta:%x iberr:%x ibcnt:%x",ibsta,iberr,ibcnt);
...
}There are 18 lines of code between declaration and first usage. The date of last modification was in 1997. The oldest sources I found are dated 1996, but I know that the initial sources must be from about 1989 (they should exist somewhere on floppy disks and printed sources may be buried somewhere in the basement storage). The colleagues from the calibration lab told me, that they always wonder why the software often locks after showing an error message.
So, "software", with over 20 year old code, AND STILL IN USE?! lol *points and laughs loudly* I wonder who will be scratching his head trying to understand my codes in 20 years... He's probably not even born yet. Ahhh, he will have a good laugh too, reading my comments in the code, and then posting snipplets here... lol
-
While porting an old DOS software to Windows that controls a temperature bath, i came across this code to show error messages:
COUNT showerr(COUNT res)
{
char *szGp;
...
sprintf(szGp,"ibsta:%x iberr:%x ibcnt:%x",ibsta,iberr,ibcnt);
...
}There are 18 lines of code between declaration and first usage. The date of last modification was in 1997. The oldest sources I found are dated 1996, but I know that the initial sources must be from about 1989 (they should exist somewhere on floppy disks and printed sources may be buried somewhere in the basement storage). The colleagues from the calibration lab told me, that they always wonder why the software often locks after showing an error message.
Jochen Arndt wrote:
controls a temperature bath
After reading this and then
showerrI wondered why the function wasn't namedbath, and noted there is a typo in the function name (the double 'r' at the end). Then I realized the posting was about something entirely different... :doh:Jochen Arndt wrote:
they always wonder why the software often locks
Woot, they wondered for decades and never demanded a fix? :omg: Can I have your users please?? :-O
-
Jochen Arndt wrote:
controls a temperature bath
After reading this and then
showerrI wondered why the function wasn't namedbath, and noted there is a typo in the function name (the double 'r' at the end). Then I realized the posting was about something entirely different... :doh:Jochen Arndt wrote:
they always wonder why the software often locks
Woot, they wondered for decades and never demanded a fix? :omg: Can I have your users please?? :-O
Stefan_Lang wrote:
Woot, they wondered for decades and never demanded a fix? :OMG: Can I have your users please?
It is a controlling app that does not require user interaction after optional initial settings upon starting it. Reported errors are serious and the app is waiting for any key press and terminates. So they decided that it does not matter. The users are not as pleasant as you think. They complain about many things. But with most questions they ask me, I ask them: Did you tried F1? ;)
-
That's pretty darn ironic... an error in the
showerr()function... :laugh:Albert Holguin wrote:
That's pretty darn ironic... an error in the
showerr()function... :laugh:yeah, ironic...believe me, if you've ever had to diagnose one, you feel, hmmm, pressed ;-)
-
So, "software", with over 20 year old code, AND STILL IN USE?! lol *points and laughs loudly* I wonder who will be scratching his head trying to understand my codes in 20 years... He's probably not even born yet. Ahhh, he will have a good laugh too, reading my comments in the code, and then posting snipplets here... lol
Last I heard, code I started maintaining in 1988 was still being used in a COM object behind a benefits enrollment system (it was ported from another program to deal with Federal Income Tax). Software archaeology is not an oxymoron.
-
Jochen Arndt wrote:
controls a temperature bath
After reading this and then
showerrI wondered why the function wasn't namedbath, and noted there is a typo in the function name (the double 'r' at the end). Then I realized the posting was about something entirely different... :doh:Jochen Arndt wrote:
they always wonder why the software often locks
Woot, they wondered for decades and never demanded a fix? :omg: Can I have your users please?? :-O
Stefan_Lang wrote:
Woot, they wondered for decades and never demanded a fix? :OMG: Can I have your users please?? :O
Can't fix it unless you can find it, and an uninitialized pointer can often be found to be pointing at something that looks like valid memory (say, some other string's buffer that isn't getting used at the moment) so the error doesn't occur all the time. Errors like this become "cold cases" because there are so few clues to follow. I sort of doubt that the users were quiet about it, either. Pertinent to but opposing a point made by someone's tag line I read today, this is why I always initialize as close to the definition as possible, just to keep in the habit - I work in environments that assume initialization as well as environments like C where assumptions make asses out of everyone.
-
While porting an old DOS software to Windows that controls a temperature bath, i came across this code to show error messages:
COUNT showerr(COUNT res)
{
char *szGp;
...
sprintf(szGp,"ibsta:%x iberr:%x ibcnt:%x",ibsta,iberr,ibcnt);
...
}There are 18 lines of code between declaration and first usage. The date of last modification was in 1997. The oldest sources I found are dated 1996, but I know that the initial sources must be from about 1989 (they should exist somewhere on floppy disks and printed sources may be buried somewhere in the basement storage). The colleagues from the calibration lab told me, that they always wonder why the software often locks after showing an error message.
Ouch!!
-
While porting an old DOS software to Windows that controls a temperature bath, i came across this code to show error messages:
COUNT showerr(COUNT res)
{
char *szGp;
...
sprintf(szGp,"ibsta:%x iberr:%x ibcnt:%x",ibsta,iberr,ibcnt);
...
}There are 18 lines of code between declaration and first usage. The date of last modification was in 1997. The oldest sources I found are dated 1996, but I know that the initial sources must be from about 1989 (they should exist somewhere on floppy disks and printed sources may be buried somewhere in the basement storage). The colleagues from the calibration lab told me, that they always wonder why the software often locks after showing an error message.
Blame can be put on the compiler that didn't raise an "uninitialized variable" warning, or triple blame on the programmer if he ignored it.
-
Blame can be put on the compiler that didn't raise an "uninitialized variable" warning, or triple blame on the programmer if he ignored it.
The originally used compiler was MSC 6. May be the latest versions has been build using VC 1.52. I don't remember if these C compilers generate such warnings. A look into the make file shows that warning level /W3 has been used.
-
Stefan_Lang wrote:
Woot, they wondered for decades and never demanded a fix? :OMG: Can I have your users please?? :O
Can't fix it unless you can find it, and an uninitialized pointer can often be found to be pointing at something that looks like valid memory (say, some other string's buffer that isn't getting used at the moment) so the error doesn't occur all the time. Errors like this become "cold cases" because there are so few clues to follow. I sort of doubt that the users were quiet about it, either. Pertinent to but opposing a point made by someone's tag line I read today, this is why I always initialize as close to the definition as possible, just to keep in the habit - I work in environments that assume initialization as well as environments like C where assumptions make asses out of everyone.
Yes, uninitialized pointers can be nasty, especially since they normally will be 0 when you look at the problem in debug builds and thus fail to reproduce the issue. But that alone (i. e. a bug that happens only in release) is enough of on an indication for me to look at initialization first. Fortunately modern runtimes will no longer accept pointers that do not point into at least the data segment, or aren't aligned properly, so you're normally able to find the culprit very fast. I, too, intialize every variable, to the point of assigning at least 0 (or
nullptr, now), even when the actual initialization happens only two lines below. The point being, that 'two lines below' will likely not remain 'only two lines' in the long run. I also sometimes use an intialization function for a class, so I can call it in each constructor. While it's more efficient to use initializers in each constructor, it's way too easy to forget one when introducing additional members later. I wonder why initializers for member variables are not allowed... :confused: -
The originally used compiler was MSC 6. May be the latest versions has been build using VC 1.52. I don't remember if these C compilers generate such warnings. A look into the make file shows that warning level /W3 has been used.
MSVC 2003 can raise two different warnings, C4700 (level 1) and C4701 (level 4), depending on the optimization flags ! http://msdn.microsoft.com/en-us/library/aa733919(v=vs.60).aspx[^] http://msdn.microsoft.com/en-us/library/aa733920(v=vs.60).aspx[^] I am sure one of them exists in MSVC 6.0. And possibly VC 1.52...
-
MSVC 2003 can raise two different warnings, C4700 (level 1) and C4701 (level 4), depending on the optimization flags ! http://msdn.microsoft.com/en-us/library/aa733919(v=vs.60).aspx[^] http://msdn.microsoft.com/en-us/library/aa733920(v=vs.60).aspx[^] I am sure one of them exists in MSVC 6.0. And possibly VC 1.52...
MSC6 is Microsoft C Compiler version 6 (no 'V') released 1990! VC 1.52c has been released 1995 and is the last version with full MS-DOS support.
-
MSC6 is Microsoft C Compiler version 6 (no 'V') released 1990! VC 1.52c has been released 1995 and is the last version with full MS-DOS support.
Yep. I started using Visual C++ with VC 1.51. You find traces of it on web pages. MSC6 is much more forgotten... (no confusion)
-
Yep. I started using Visual C++ with VC 1.51. You find traces of it on web pages. MSC6 is much more forgotten... (no confusion)
I still have an VC 1.52 installation in XP Mode and checked the help: Warnings C4700 and C4701 are present but require /Oe (global register allocation) which is not set in the make file.
-
I still have an VC 1.52 installation in XP Mode and checked the help: Warnings C4700 and C4701 are present but require /Oe (global register allocation) which is not set in the make file.
IMHO such a condition (potentially uninitialized variable) should be signalled by default by any compiler because this can rescue you from painful bugs. Further inquiry led me two find two interesting features: 1) a list of warnings that are turned off by default, http://msdn.microsoft.com/en-us/library/23k5d385.aspx[^] 2) the good way to temporarily disable the warning when it becomes disturbing: http://msdn.microsoft.com/en-us/library/2c8f766e.aspx[^],
suppressspecifier. -
IMHO such a condition (potentially uninitialized variable) should be signalled by default by any compiler because this can rescue you from painful bugs. Further inquiry led me two find two interesting features: 1) a list of warnings that are turned off by default, http://msdn.microsoft.com/en-us/library/23k5d385.aspx[^] 2) the good way to temporarily disable the warning when it becomes disturbing: http://msdn.microsoft.com/en-us/library/2c8f766e.aspx[^],
suppressspecifier.YvesDaoust wrote:
IMHO such a condition (potentially uninitialized variable) should be signalled by default by any compiler because this can rescue you from painful bugs.
C4700 is a level 1 warning and therefore shown by default (the /Oe limitation does not exist anymore for actual compilers). With debug versions, I always use level 4. Code is not allowed to be released, if there are any warnings. In some special cases, I use the method from your 2nd link to disable warnings including a comment. Thank you for the 1st link. I did not know about until now.
-
YvesDaoust wrote:
IMHO such a condition (potentially uninitialized variable) should be signalled by default by any compiler because this can rescue you from painful bugs.
C4700 is a level 1 warning and therefore shown by default (the /Oe limitation does not exist anymore for actual compilers). With debug versions, I always use level 4. Code is not allowed to be released, if there are any warnings. In some special cases, I use the method from your 2nd link to disable warnings including a comment. Thank you for the 1st link. I did not know about until now.
Strange that the warning levels did depend on the optimization levels. In theory, optimization is fully transparent to the program semantics, isn't it ? "Code is not allowed to be released, if there are any warnings": it is tempting for some developers to bypass this by just disabling the warnings. As heavy as this may be, such twists should be appropriately commented.
-
Strange that the warning levels did depend on the optimization levels. In theory, optimization is fully transparent to the program semantics, isn't it ? "Code is not allowed to be released, if there are any warnings": it is tempting for some developers to bypass this by just disabling the warnings. As heavy as this may be, such twists should be appropriately commented.
YvesDaoust wrote:
Strange that the warning levels did depend on the optimization levels. In theory, optimization is fully transparent to the program semantics, isn't it ?
Of course. But the used compilers are historic.
YvesDaoust wrote:
"Code is not allowed to be released, if there are any warnings": it is tempting for some developers to bypass this by just disabling the warnings. As heavy as this may be, such twists should be appropriately commented.
They must be commented. But there are situations where warnings may be disabled. An example would be using DAO which floods the output with C4995 warnings (name was marked as #pragma deprecated).