Identifying sequence point errors in VS6
-
See http://c-faq.com/expr/evalorder1.html[^] and http://c-faq.com/expr/seqpoints.html[^]. a[i] = i++ is disallowed. GCC has flags "gcc –Wsequence-point –Werror " to detect these errors, can microsoft compiler detect this? I use Visual Studio 6. If the CL compiler in VS6 cannot detect it, how about VS2003 and VS2005? thanks!
-
See http://c-faq.com/expr/evalorder1.html[^] and http://c-faq.com/expr/seqpoints.html[^]. a[i] = i++ is disallowed. GCC has flags "gcc –Wsequence-point –Werror " to detect these errors, can microsoft compiler detect this? I use Visual Studio 6. If the CL compiler in VS6 cannot detect it, how about VS2003 and VS2005? thanks!
I have not looked at the sights you provided, but that is not an error. A warning might not be a bad idea for that, but come on (it's legal code). INTP Every thing is relative...
-
I have not looked at the sights you provided, but that is not an error. A warning might not be a bad idea for that, but come on (it's legal code). INTP Every thing is relative...
Is is actually disallowed in C as it can lead to undefined behaviour, see the two links I gave. GCC takes a command line option to detect this as a warning. thanks!
-
See http://c-faq.com/expr/evalorder1.html[^] and http://c-faq.com/expr/seqpoints.html[^]. a[i] = i++ is disallowed. GCC has flags "gcc –Wsequence-point –Werror " to detect these errors, can microsoft compiler detect this? I use Visual Studio 6. If the CL compiler in VS6 cannot detect it, how about VS2003 and VS2005? thanks!
Did you change the warning level to 4? (Project->Settings->C/C++) Elaine :rose: The tigress is here :-D
-
Did you change the warning level to 4? (Project->Settings->C/C++) Elaine :rose: The tigress is here :-D
Trollslayer wrote:
Did you change the warning level to 4? (Project->Settings->C/C++)
I just checked with both VS6 and VS 2003, both of them dont detect and warn for a[i] = i++. Do you have VS 2005 to check this out? GCC 3.4.3 does, if you want to check this out with GCC. thanks!
-
Trollslayer wrote:
Did you change the warning level to 4? (Project->Settings->C/C++)
I just checked with both VS6 and VS 2003, both of them dont detect and warn for a[i] = i++. Do you have VS 2005 to check this out? GCC 3.4.3 does, if you want to check this out with GCC. thanks!
I just tried on VS2005 with warning level 4 and it wasn't reported. The tigress is here :-D
-
I have not looked at the sights you provided, but that is not an error. A warning might not be a bad idea for that, but come on (it's legal code). INTP Every thing is relative...
John R. Shaw wrote:
I have not looked at the sights you provided, but that is not an error. A warning might not be a bad idea for that, but come on (it's legal code).
Actually, it does violate the standard: "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored." The second sentence is the killer here. I think it's a silly statement, but perhaps that's just me. To me, it would be more intuitive to state that an object's value is not changed until the compiler reaches a sequence point - nice and clean and predictable, without preventing totally unambiguous code such as this example.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Is is actually disallowed in C as it can lead to undefined behaviour, see the two links I gave. GCC takes a command line option to detect this as a warning. thanks!
I assume you intended saying "It is actually disallowed...", but the rest of your statement does not support that nor does the standard. The term "undefined behaviour" does not disallow a programmer from doing it. It just says its behaviour is undefined in the standard and is therefore compiler dependent. Meaning that you can not determine the result when using a different compiler, provided it worked on your current compiler. A fully compliant compiler could compile that statement without giving any warning at all. But is should at the least give a warning and at the most consider it an error (becuase it is undefined behaviour). INTP Every thing is relative...
-
John R. Shaw wrote:
I have not looked at the sights you provided, but that is not an error. A warning might not be a bad idea for that, but come on (it's legal code).
Actually, it does violate the standard: "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored." The second sentence is the killer here. I think it's a silly statement, but perhaps that's just me. To me, it would be more intuitive to state that an object's value is not changed until the compiler reaches a sequence point - nice and clean and predictable, without preventing totally unambiguous code such as this example.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
Ryan Binns wrote:
Actually, it does violate the standard
Actually, undefined behaviour is not a violation of the standard. It is what it says "undefined", that means it is up to the compiler [vender] to determine what its behaviour is. Personaly, I think it should translate into:
data[i] = i;
++i;OR
data[i] = (temp = i + 1);
i = temp;but that is just my opinion. INTP Every thing is relative...
-
I assume you intended saying "It is actually disallowed...", but the rest of your statement does not support that nor does the standard. The term "undefined behaviour" does not disallow a programmer from doing it. It just says its behaviour is undefined in the standard and is therefore compiler dependent. Meaning that you can not determine the result when using a different compiler, provided it worked on your current compiler. A fully compliant compiler could compile that statement without giving any warning at all. But is should at the least give a warning and at the most consider it an error (becuase it is undefined behaviour). INTP Every thing is relative...
John R. Shaw wrote:
A fully compliant compiler could compile that statement without giving any warning at all. But is should at the least give a warning and at the most consider it an error (becuase it is undefined behaviour).
So it may be the case that the C compilers shipped with VS6, VS2003, VS2005 all aren't fully compliant with the standard. What is puzzling is, they dont qualify your "at the least" part, forget about "at the most" part. thanks! -- modified at 0:55 Sunday 19th March, 2006
-
John R. Shaw wrote:
A fully compliant compiler could compile that statement without giving any warning at all. But is should at the least give a warning and at the most consider it an error (becuase it is undefined behaviour).
So it may be the case that the C compilers shipped with VS6, VS2003, VS2005 all aren't fully compliant with the standard. What is puzzling is, they dont qualify your "at the least" part, forget about "at the most" part. thanks! -- modified at 0:55 Sunday 19th March, 2006
I would need to look it up, because I never understood why it would be classified as undefined behaviour. :doh: My answer was very weak and I should not have attempted it [without research], becuase it actually applies to the "old argument" below, following my explination of what I ment. I said "at the least" because if it is undefined behaviour then it would be compiler dependent (non-portable) and a warning should be generated to inform the programmer of this. I said "at the most" because if it is undefined behaviour then it would be compiler dependent and an error would force the programmer not to write non-poratable code. I believed it was consider undefined behaviour in the passed, which means the compiler vender could decide what behaviour to apply, and still be fully compliant. This may no longer be the case, as the behaviour may now be deifined. Here is the old argument:
int i = 0; i = i++;Should i now be equal to 0 or 1? My answer and the answer Microsoft chose is 1, which I think is the only logical answer. But there where those who disagreed and said the answer should be 0, because they believed that was the intent of the progammer. So if you throw out logic and just consider the intent, then the language would not be able to define the behaviour. I think the real problem was that different venders had already implimented different solutions, before the standared was complete. When I originaly gave my answer of 1 to that question (years ago), I was informed that my answer was wrong, becuase it was undefined and therefore could be either 0 or 1. VS6 may be fully compliant for C (?), but it is not fully compliant with the C++ standard. VS2003, according to Microsoft, is a full ASCII/ISO C++ Standards compliant compiler. INTP Every thing is relative...