Bug found in GCC-AVR/ AVRStudio

In article <va0pu0l424jitu2lr86s29332raie0j7j0@4ax.com>, 
jackklein@spamcop.net says...
> On Mon, 17 Jan 2005 13:25:33 -0500, R Adsett
> <radsett@junk.aeolusdevelopment.cm> wrote in comp.arch.embedded:
> > 
> > If you do this, however, 
> > 
> > char * ty = "hello";
> 
> 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.

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.  

Robert

dereklai2k@yahoo.com.hk wrote:
> 
> 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.

PLONK for total uncooperativeness.

-- 
"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

leonlai2k@yahoo.com wrote:
> 
> May be u can pop the reply tree at the left side to help u locate the
> link positions.

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

On 17 Jan 2005 19:11:07 -0800, leonlai2k@yahoo.com wrote:

>May be u can pop the reply tree at the left side to help u locate the
>link positions.

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.


>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.

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 <same-name>@epost.de instead !

On 17 Jan 2005 00:21:47 -0800, dereklai2k@yahoo.com.hk wrote:

>I have written the careless mistake in the previous thread I posted.
>Please check!
>

Ok, I think your another one on my spam-list, so I don't waste my time
reading your posts.
-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@epost.de instead !

On Mon, 17 Jan 2005 15:24:00 +0000, Grant Edwards wrote:

> On 2005-01-17, David <david.nospam@westcontrol.removethis.com> wrote:
> 
>>> Same problem exists. Actually I tried const char firstly, but GCC
>>> seemed to regard it as ram data.
>>
>> const data *is* ram data.
> 
> Not in my systems it isn't.  I tell the linker to put const
> data in ROM along with the code.
> 

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.

>> C does not have real constants - the term "const" is only a
>> hint to the compiler that you probably won't change it, unless
>> you really mean it.  So compilers that put "const" data into
>> flash are breaking the C standard (not necessarily a bad idea
>> - but gcc doesn't like to break the standard).
> 
> gcc puts const data into seperate sections.  The linker puts
> them into RAM vs. flash vs. whatever.
> 
>> If you read the avrlibc documentation, you'll find how to put
>> strings in flash.

On Mon, 17 Jan 2005 21:23:33 -0600, Jack Klein wrote:

> On Mon, 17 Jan 2005 08:36:51 +0100, David
> <david.nospam@westcontrol.removethis.com> wrote in comp.arch.embedded:
> 
>> On Sun, 16 Jan 2005 06:38:03 -0800, dereklai2k wrote:
>> 
>> > Same problem exists. Actually I tried const char firstly, but GCC
>> > seemed to regard it as ram data.
>> 
>> const data *is* ram data.  C does not have real constants - the term
>> "const" is only a hint to the compiler that you probably won't change it,
>> unless you really mean it.  So compilers that put "const" data into flash
>> are breaking the C standard (not necessarily a bad idea - but gcc doesn't
>> like to break the standard).  If you read the avrlibc documentation,
>> you'll find how to put strings in flash.
> 
> You are absolutely wrong about what the C standard does and does not
> specify.

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.

David


> 
> 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.
> 
>> char version[10]="1.0";
> 
> 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.

On Tue, 18 Jan 2005 10:14:48 +0100, David wrote:

> On Mon, 17 Jan 2005 15:24:00 +0000, Grant Edwards wrote:
> 
>> On 2005-01-17, David <david.nospam@westcontrol.removethis.com> wrote:
>> 
>>>> Same problem exists. Actually I tried const char firstly, but GCC
>>>> seemed to regard it as ram data.
>>>
>>> const data *is* ram data.
>> 
>> Not in my systems it isn't.  I tell the linker to put const
>> data in ROM along with the code.
>> 
> 
> 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. 

I've now been corrected - casting a const to a non-const is not legal C.

> 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.
> 
>>> C does not have real constants - the term "const" is only a
>>> hint to the compiler that you probably won't change it, unless
>>> you really mean it.  So compilers that put "const" data into
>>> flash are breaking the C standard (not necessarily a bad idea
>>> - but gcc doesn't like to break the standard).
>> 
>> gcc puts const data into seperate sections.  The linker puts
>> them into RAM vs. flash vs. whatever.
>> 
>>> If you read the avrlibc documentation, you'll find how to put
>>> strings in flash.

<leonlai2k@yahoo.com> wrote in message
news:1106017867.730516.122740@f14g2000cwb.googlegroups.com...
> 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.

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

Meindert

In article <K6SdnVdUEum6CHHcRVn-jg@rogers.com>, 
radsett@junk.aeolusdevelopment.cm says...
> 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.

Hmm, that sounds a little petulant.

> And you are of course right, you aren't supposed to write to the literal.  

This should really be the core of the response.

Robert