Those missing commas...
-
The following code had been in Production use for 10 years at my company. It started crashing when we converted from vc6 to vc8: selectSql += "SELECT FieldA, FieldB, FieldC FieldD from TableA where ORG_ID = 'xxx'"; rc = rs.open(selectSql); while ( !rs.isEOF() && !rs.isError() ) { pInput = new PDUpdateInput; pInput->FieldAValue = rs.getResultLong(0); pInput->FieldBValue = rs.getResult(1); pInput->FieldCValue = rs.getResult(2); pInput->FieldDValue = rs.getResult(3); // Crashed here! lst->push_back(pInput); rc = rs.moveNext(); } rs.close(); Obviously, we never used FieldD for anything, because that value was never retrieved! The comma is missing between FieldC and FieldD in the Select statement. That makes the string 'FieldD' an alias to FieldC. Apparently, the security in vc8 is stepped up (compared to vc6), so when trying to access rs.getResult(3) it crashed since there are only 3 values in the resultset, not 4. This didn't take long at all to find/fix. But it's amazing sometimes how long bugs can be in Production code and stay hidden.
-
The following code had been in Production use for 10 years at my company. It started crashing when we converted from vc6 to vc8: selectSql += "SELECT FieldA, FieldB, FieldC FieldD from TableA where ORG_ID = 'xxx'"; rc = rs.open(selectSql); while ( !rs.isEOF() && !rs.isError() ) { pInput = new PDUpdateInput; pInput->FieldAValue = rs.getResultLong(0); pInput->FieldBValue = rs.getResult(1); pInput->FieldCValue = rs.getResult(2); pInput->FieldDValue = rs.getResult(3); // Crashed here! lst->push_back(pInput); rc = rs.moveNext(); } rs.close(); Obviously, we never used FieldD for anything, because that value was never retrieved! The comma is missing between FieldC and FieldD in the Select statement. That makes the string 'FieldD' an alias to FieldC. Apparently, the security in vc8 is stepped up (compared to vc6), so when trying to access rs.getResult(3) it crashed since there are only 3 values in the resultset, not 4. This didn't take long at all to find/fix. But it's amazing sometimes how long bugs can be in Production code and stay hidden.
Years ago, when I was (much younger, and) a mainframe Assembler and COBOL programmer, working away in a room full of other COBOL programmers, suddenly a co-worker who had apparently been looking for the flaw in her code for some number of hours blurted out: "Oh! I missed my period!" Needless to say, much hilarity ensued.
-
The following code had been in Production use for 10 years at my company. It started crashing when we converted from vc6 to vc8: selectSql += "SELECT FieldA, FieldB, FieldC FieldD from TableA where ORG_ID = 'xxx'"; rc = rs.open(selectSql); while ( !rs.isEOF() && !rs.isError() ) { pInput = new PDUpdateInput; pInput->FieldAValue = rs.getResultLong(0); pInput->FieldBValue = rs.getResult(1); pInput->FieldCValue = rs.getResult(2); pInput->FieldDValue = rs.getResult(3); // Crashed here! lst->push_back(pInput); rc = rs.moveNext(); } rs.close(); Obviously, we never used FieldD for anything, because that value was never retrieved! The comma is missing between FieldC and FieldD in the Select statement. That makes the string 'FieldD' an alias to FieldC. Apparently, the security in vc8 is stepped up (compared to vc6), so when trying to access rs.getResult(3) it crashed since there are only 3 values in the resultset, not 4. This didn't take long at all to find/fix. But it's amazing sometimes how long bugs can be in Production code and stay hidden.
I met someone who sitted for about 3 hours to look for a bug in his code. The input was a two dimentional array (a table) and the output supposed to be a next state of the same table. His result was the same table every time. Here is the code snippet:
// Tons of code here ... for(int i=0;i<10;++i); for(int j=0;j<10;++j) { int c = table[i][j]; // Do something with c, etc. } // More tons of code hereAt first it is hard to notice, but at the end of the firstforthere is a semicolon that doesn't suppose to be there. When I pointed out for the poor guy he was about to go mad. Ami -
I met someone who sitted for about 3 hours to look for a bug in his code. The input was a two dimentional array (a table) and the output supposed to be a next state of the same table. His result was the same table every time. Here is the code snippet:
// Tons of code here ... for(int i=0;i<10;++i); for(int j=0;j<10;++j) { int c = table[i][j]; // Do something with c, etc. } // More tons of code hereAt first it is hard to notice, but at the end of the firstforthere is a semicolon that doesn't suppose to be there. When I pointed out for the poor guy he was about to go mad. AmiAmi Bar wrote:
At first it is hard to notice, but at the end of the first for there is a semicolon
For this reason, I always use braces with
if,foretc. Even when using only one statment. And I place my braces in the same line as the opening statement. This way, I easly spot the semicolon where never could be one.for(int i=0;i<10;++i); {
for(int j=0;j<10;++j) {
int c = table[i][j];
// Do something with c, etc.
}
}It sticks out, I think. Also, there may be a compiler warning, I think.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
-
Ami Bar wrote:
At first it is hard to notice, but at the end of the first for there is a semicolon
For this reason, I always use braces with
if,foretc. Even when using only one statment. And I place my braces in the same line as the opening statement. This way, I easly spot the semicolon where never could be one.for(int i=0;i<10;++i); {
for(int j=0;j<10;++j) {
int c = table[i][j];
// Do something with c, etc.
}
}It sticks out, I think. Also, there may be a compiler warning, I think.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
I use a similar rule : I always use braces with if, for etc,.. IF the whole statement is not on one line : For example :
if(value = requiredValue) count++;no braces. A semicolon might eventually appears between the if and the count++ but that's not a problem since the language i usually use (c#) raise an error in that case : "Possible mistaken null statement". Now that I think about it, in c/c++ it might compile without any error reported. However if the if statement would be too big to fit on one line i won't do :if(value = requiredValue & someotherverylargeverification) aVeryLargeOperation(parameter1, parameter 2);Instead I always transform it to use braces :if(value = requiredValue & someotherverylargeverification) { aVeryLargeOperation(parameter1, parameter 2); }I do that because the day you need to do another operation in the if you might accidently do :if(value = requiredValue & someotherverylargeverification) aVeryLargeOperation(parameter1, parameter 2); aSecondOperation();It might sounds stupid to do that but that already saw it happen to other and to myself. Once i had to step through the code with a debugger until i noticed that aSecondOperation(); was executed even though the if condition was false and i was like WTF is going on here? When i realised what silly mistake i done i felt really ashamed. I am currently programming in VB.NET and those kind of error just can't happen. You can't do assignations in an if statement in vb and braces are replaced by If Then Else End If which make it far more easier to spot errors such as the one mentionned above. -
I use a similar rule : I always use braces with if, for etc,.. IF the whole statement is not on one line : For example :
if(value = requiredValue) count++;no braces. A semicolon might eventually appears between the if and the count++ but that's not a problem since the language i usually use (c#) raise an error in that case : "Possible mistaken null statement". Now that I think about it, in c/c++ it might compile without any error reported. However if the if statement would be too big to fit on one line i won't do :if(value = requiredValue & someotherverylargeverification) aVeryLargeOperation(parameter1, parameter 2);Instead I always transform it to use braces :if(value = requiredValue & someotherverylargeverification) { aVeryLargeOperation(parameter1, parameter 2); }I do that because the day you need to do another operation in the if you might accidently do :if(value = requiredValue & someotherverylargeverification) aVeryLargeOperation(parameter1, parameter 2); aSecondOperation();It might sounds stupid to do that but that already saw it happen to other and to myself. Once i had to step through the code with a debugger until i noticed that aSecondOperation(); was executed even though the if condition was false and i was like WTF is going on here? When i realised what silly mistake i done i felt really ashamed. I am currently programming in VB.NET and those kind of error just can't happen. You can't do assignations in an if statement in vb and braces are replaced by If Then Else End If which make it far more easier to spot errors such as the one mentionned above.Monkeyget2 wrote:
A semicolon might eventually appears between the if and the count++ but that's not a problem since the language i usually use (c#) raise an error in that case : "Possible mistaken null statement". Now that I think about it, in c/c++ it might compile without any error reported.
Well, in fact all newer C++ - compilers warn, and if you program in a way so as not to get overwhelmed by thousands of warnings, you could notice. I think there is also a way to bring the compiler to make an error out of aspecific warning. (With all warnings its easy, but a bit pointless).
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.