Why is this allowed
-
When you run some code like below - which AFAIK is highly illegal, it will crash miserabely in debug builds, but it works OK in release builds.
char* p="Not testing";
strcpy(p, "Testing");My question is: Is this a feature or a bug, and will it always work? Christian Skovdal Andersen "I have a plan so cunning you could put a tail on it and call it a weasel." -Edmund, Blackadder III
-
When you run some code like below - which AFAIK is highly illegal, it will crash miserabely in debug builds, but it works OK in release builds.
char* p="Not testing";
strcpy(p, "Testing");My question is: Is this a feature or a bug, and will it always work? Christian Skovdal Andersen "I have a plan so cunning you could put a tail on it and call it a weasel." -Edmund, Blackadder III
Actually, it's entirely legal. It's not a constant string, so the compiler assumes you know what you're doing. :) If it was:
const char *p = "Not testing";
strcpy(p, "Testing");the compiler would yell at you because strcpy() doesn't know how to stomp on a constant string. As well, if it was:
char * const p = "Not testing";
p = "Wankity wank";the compiler would yell at you for trying to assign to a const object. J
-
Actually, it's entirely legal. It's not a constant string, so the compiler assumes you know what you're doing. :) If it was:
const char *p = "Not testing";
strcpy(p, "Testing");the compiler would yell at you because strcpy() doesn't know how to stomp on a constant string. As well, if it was:
char * const p = "Not testing";
p = "Wankity wank";the compiler would yell at you for trying to assign to a const object. J
It's not legal, actually. Its behavior is undefined, according to my copy of the ARM (section 2.5.4). The fact that they made string literals char* instead of const char * is simply a hack for compatibility with existing C programs. Tim Lesher http://www.lesher.ws
-
It's not legal, actually. Its behavior is undefined, according to my copy of the ARM (section 2.5.4). The fact that they made string literals char* instead of const char * is simply a hack for compatibility with existing C programs. Tim Lesher http://www.lesher.ws
My mistake. :-O J
-
When you run some code like below - which AFAIK is highly illegal, it will crash miserabely in debug builds, but it works OK in release builds.
char* p="Not testing";
strcpy(p, "Testing");My question is: Is this a feature or a bug, and will it always work? Christian Skovdal Andersen "I have a plan so cunning you could put a tail on it and call it a weasel." -Edmund, Blackadder III
String literals are not constant strings. They can be changed at runtime. Now, there are two problems with do that. First, many compilers support string pooling. char *pszA = "test"; char *pszB = "test"; When these two lines compile, pszA and pszB will point to the same memory space. Thus, if you change one, you change them both. This really isn't a problem unless one part of the program is expecting the *pszA to remain contant while another part is expecting *pszB to be modified. Second, many compilers support storing strings in readonly memory. IMHO, this is the way to go. Then strings can safely be pooled. Tim Smith Descartes Systems Sciences, Inc.
-
It's not legal, actually. Its behavior is undefined, according to my copy of the ARM (section 2.5.4). The fact that they made string literals char* instead of const char * is simply a hack for compatibility with existing C programs. Tim Lesher http://www.lesher.ws
Its behavior is undefined Which is why I giggle when people scream for compiler standards. Standards are great, but too many people think that 100% compiler standard means the compilers will operate 100% the same. Which of course, anybody who has worked with standards knows is a joke. Tim Smith Descartes Systems Sciences, Inc.
-
It's not legal, actually. Its behavior is undefined, according to my copy of the ARM (section 2.5.4). The fact that they made string literals char* instead of const char * is simply a hack for compatibility with existing C programs. Tim Lesher http://www.lesher.ws
-
Its behavior is undefined Which is why I giggle when people scream for compiler standards. Standards are great, but too many people think that 100% compiler standard means the compilers will operate 100% the same. Which of course, anybody who has worked with standards knows is a joke. Tim Smith Descartes Systems Sciences, Inc.
Tim Smith quoted: Its behavior is undefined AFAIR, "undefined behavior" is (by usage of at least the C standard) something absolutely illegal, but not necessarily flagged by the compiler. Someone describet it as "the compiler might melt down the universe, without violating the standard". On a "write everywhere" platform this would be ok (if the compiler doesn't merge literals), which sounds like a good reason to let it through. OTOH, applied to HTML, you#re absolutely right ;-)
-
Tim Smith quoted: Its behavior is undefined AFAIR, "undefined behavior" is (by usage of at least the C standard) something absolutely illegal, but not necessarily flagged by the compiler. Someone describet it as "the compiler might melt down the universe, without violating the standard". On a "write everywhere" platform this would be ok (if the compiler doesn't merge literals), which sounds like a good reason to let it through. OTOH, applied to HTML, you#re absolutely right ;-)
Actually, I am totally right with C++ or HTML. The construct being undefined (illegal) or unspecified (legal) is basically irrelevant when programmers unknowingly take advantage of a compiler's 'features'. When we write software, we are CONSTANTLY taking advantage of undefined or unspecified features in a compiler or OS. It isn't like we have a master program that we can submit our software to that verifies that we not using undefined or unspecified functionality. We tend to write software and tweak code until it works (hopefully, most of us are a bit more professional than that). For example:
int i = 0;
int a [10];a [i] = i++;
Which variable is set, a [0] or a [1]? Well, according to the standard, it is unspecified. Thus, if a programmer actually did that, then his software would work on some compilers and not others. Standards help to move us towards multi-platform code, but in no way will remove compiler dependencies in source code. As a friend of mine said when hearing of the first release of the POSIX standard, "Oh, gee, now we have a standard way to write to a file." As another friend of mine said about their VMS operating system and the POSIX standard, "We are one of the first POSIX compliant operating systems. All we had to do was release a document staying where we weren't standard." Tim Smith Descartes Systems Sciences, Inc.
-
Its behavior is undefined Which is why I giggle when people scream for compiler standards. Standards are great, but too many people think that 100% compiler standard means the compilers will operate 100% the same. Which of course, anybody who has worked with standards knows is a joke. Tim Smith Descartes Systems Sciences, Inc.
Tim Smith wrote: Standards are great, but too many people think that 100% compiler standard means the compilers will operate 100% the same. Does the fact that the standard is not airtight mean that it would be a bad thing for all compilers to operate the same on those parts of the standard that are clear? All compilers will never operate 100% the same, if for no other reason than that they target different processors (sizeof(int) SHOULD be different for a 8051, 8086, 80386, ia64, etc. The real reason for insisting on standards-compliance is that there are many useful libraries many of us would like to work with, which VC++ 7.0 cannot use because the libraries make significant use of features of standard C++ that VC++ has chosen not to support.
-
Tim Smith wrote: Standards are great, but too many people think that 100% compiler standard means the compilers will operate 100% the same. Does the fact that the standard is not airtight mean that it would be a bad thing for all compilers to operate the same on those parts of the standard that are clear? All compilers will never operate 100% the same, if for no other reason than that they target different processors (sizeof(int) SHOULD be different for a 8051, 8086, 80386, ia64, etc. The real reason for insisting on standards-compliance is that there are many useful libraries many of us would like to work with, which VC++ 7.0 cannot use because the libraries make significant use of features of standard C++ that VC++ has chosen not to support.
Does the fact that the standard is not airtight mean that it would be a bad thing for all compilers to operate the same on those parts of the standard that are clear? Did I say that? No. What I am saying is I really question what people expect from standards. Even the most reasonable expectation that libraries might be portable are very questionable. Take a look at www.boost.org. It isn't just MS that can't build this stuff. Tim Smith Descartes Systems Sciences, Inc.
-
Its behavior is undefined Which is why I giggle when people scream for compiler standards. Standards are great, but too many people think that 100% compiler standard means the compilers will operate 100% the same. Which of course, anybody who has worked with standards knows is a joke. Tim Smith Descartes Systems Sciences, Inc.
Yes, though you can make a (pretty good) argument that in cases where the standard says the behavior is undefined, then don't program it that way. For instance, the example given could be coded as followed, and work just fine (unless I messed up the call to "strdup", too used to using CString) char *p = strdup("Not testing"); strcpy(p, "Testing"); It seems silly to do something that is "undefined", althought maybe it'll work with your particualr compiler, when there is a legal and valid way to do it. Not that that was the original question... ;) The early bird may get the worm, but the second mouse gets the cheese.
-
Yes, though you can make a (pretty good) argument that in cases where the standard says the behavior is undefined, then don't program it that way. For instance, the example given could be coded as followed, and work just fine (unless I messed up the call to "strdup", too used to using CString) char *p = strdup("Not testing"); strcpy(p, "Testing"); It seems silly to do something that is "undefined", althought maybe it'll work with your particualr compiler, when there is a legal and valid way to do it. Not that that was the original question... ;) The early bird may get the worm, but the second mouse gets the cheese.
-
String literals are not constant strings. They can be changed at runtime. Now, there are two problems with do that. First, many compilers support string pooling. char *pszA = "test"; char *pszB = "test"; When these two lines compile, pszA and pszB will point to the same memory space. Thus, if you change one, you change them both. This really isn't a problem unless one part of the program is expecting the *pszA to remain contant while another part is expecting *pszB to be modified. Second, many compilers support storing strings in readonly memory. IMHO, this is the way to go. Then strings can safely be pooled. Tim Smith Descartes Systems Sciences, Inc.
Actually, String literals *ARE* constant strings. However, C++ supports a conversion between a constant string literal and a non-const pointer, though this behavior is officially deprecated, it's still supported for now. In a future revision of the C++ standard, the support will go away and the conversion will no longer be allowed. -- Where are we going? And why am I in this handbasket?