No, I meant what a wrote (suprisingly enough). A modifiable pointer to a modifiable string. That construct is I suspect the reason strings are not const (too many warning messages in compiling old programs that don't use const).
I have clarified in that post what the silly mistake is. And questions in that post is unrelated to questions of this post. So I do not tell u one more what the silly mistake is in this post to avoid confusion. Do not say I have not clarifed, I have already clarified a long time ago after your first advice. please check clearly and firstly.
May be u can pop the reply tree at the left side to help u locate the link positions.
As I have seen other threads there are a lot of posts not quoting and I feel no problem to see the posts. So I also have not this custom to quote texts. I do not understand why u have so much difficulties to see.
On Mon, 17 Jan 2005 08:36:51 +0100, David wrote in comp.arch.embedded:
You are absolutely wrong about what the C standard does and does not specify.
You are right about the fact that C does not guarantee that any object will be stored in memory that is physically unwriteable by a program.
But you are wrong about the fact that compilers that put "const" data into flash are breaking the C standard. Far from it. In fact, a strictly conforming C program can never tell if objects defined with the const qualifier are in read-write or read-only memory. The moment a C program attempts to modify any object defined with the const qualifier, it ceases to be a strictly conforming C program, or even a legal C program at all.
Not only does this apply to objects defined const, it applies to string literals as well, although this does not apply to the OP's original post.
This definition, in the OP's post, defines an array of 10 plain old ordinary modifiable characters, initializes the first 3 of them with '1', '.', and '0', and initializes the last 7 of them with '\0'. If the tool set, perhaps at the link stage, could determine that the program never modified this array, it could place it in read-only memory. If it could not verify that, and most tool sets can't, then it must be placed in RAM.
On the other hand, these definitions:
char *version = "1.0"; const int cint = 42;
...define data objects that can be placed in memory that the program cannot modify, like ROM, EPROM or flash. The int object because it is defined const, and the string literal because the C standard specifically states that attempting to modify a string literal produces undefined behavior.
As others have pointed out in this thread, compilers generally put data like my two examples above into a specific segment, often with a name like "const" or ".const". It is up to later steps, such as a linker or loader, to decide where in physical memory that segment is located.
But any C program which can tell in any way whether 'version' or 'cint' above are in read-only or read-write memory is not a legal C program.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
On Mon, 17 Jan 2005 13:25:33 -0500, R Adsett wrote in comp.arch.embedded:
Your first two examples are correct, but this last one is wrong. The pointer 'ty' is initialized with the address of a string literal. The type of a string literal in C is array of char (not array of const char as it is in C++), but paragraph 6 of section 6.4.5 "String literals" of the C standard specifically states that attempts to modify a string literal cause undefined behavior.
See also this question/answer from the comp.lang.c FAQ:
16.6 Why does the code "char *p = "hello, world!"; p[0] = 'H';" crash?
formatting link
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Yep, I didn't say it made sense. It really was the type I was referring to. The fact that the literal is a plain char type ( and not a const) implies that it is writeable. The fact that it isn't, is shall we say, counter-intuitive. It's a bit of the past hanging around though.
A good lint will catch this but only to so many levels of indirection. At some point they get lost.
And you are of course right, you aren't supposed to write to the literal.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
You (not u) have no idea what you are talking about. The world does not revolve around google. There is no such thing as a reply tree, a left side, etc.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
I ( this is really just one letter :) have a my tea pot on the left side and the mouse on the right side, but I don't claim this to be a standard among professional developers.
It is common sense to quote to what you are referring, so if you like to get answers for your problems, you should act like this.
--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @epost.de instead !
That's up to you, and how you use the linker. The point is that C does not enforce this, and it is valid to cast a "const" item to non-const and then change it. It is also valid to cast a non-const item (or pointer to a non-const) to a const item (or pointer to a const) and use it. On a system with a single memory space (such as an msp430), the most sensible default linker arrangement would be to put the "const" section in flash. Casting a const to a non-const and changing it will then compile, but simply won't work at run-time, while casting non-consts to consts will work. In practice, this will be fine for all but the most perverse programmers. However, if you really want to, you are free to link the const section into ram and copy over the initial values on startup. On a system such as the avr, which has seperate memory spaces, this is exactly what the compiler (and linker) *must* do, to conform with C standards, since code generated to read data from ram would not be able to read data in flash.
In the face of such opposition, I looked up some references - you are right. The standard says that the effect of code such as:
const int i = 100; *((int *) &i) = 101;
is undefined. I was under the impression that this was legal, albeit bad programming practice. Perhaps it is legal under more general or older C standards (there are so many), but illegal in ANSI C ?
In the specific case of the AVR, a compiler that puts const data in flash is still breaking the standards, since code such as:
int i = 100; const int *p = &i;
*is* legal. You can add a const qualifier if you want. On the avr, assembly code for reading flash and reading ram are quite different, so this code would not work on compilers (such as ImageCraft's) which put const data in flash.
I suppose an avr compiler could get round this by using three-byte pointers, but that would be somewhat inefficient.
First: it is common netiquette to quote what you are replying to. Second: I can subscribe to a newsgroup at any time and see your reply while not seeing the original post (not on the server anymore) you are replying to. And at such a point, your reply is completely bollocks to me
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.