Bug found in GCC-AVR/ AVRStudio

On 17 Jan 2005 15:24:00 GMT, Grant Edwards <grante@visi.com> 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.

Won't help you on an AVR.  Harvard architecture.  The compiler has to
know the data is in ROM (Flash), or it will just read RAM.

Avr-gcc has some elaborate macros to help you out, e.g. (untested)

   #include <avr/pgmspace.h>

   const char my_string[] PROGMEM = "Hello World";
   char c;
   int i;

   c = pgm_read_byte(my_string);
   for (i=0; c; c=pgm_read_byte(my_string+(i++)))
      putchar(c);

PROGMEM expands into an __attribute__, and pgm_read_byte into in-line
assembly.

Some other compilers have memory space specifiers as a language
extension:

   flash char my_string[] = "Hello World";

But (at least with the ones I'm familiar with) you either have to call
special library functions (putsf vs. puts) or copy the data into RAM.

Regards,
        
                               -=Dave
-- 
Change is inevitable, progress is not.

In article <Xns95E17D7D06142richardrapiernetscap@130.133.1.4>, 
RichardRapier@netscape.net says...
> R Adsett <radsett@junk.aeolusdevelopment.cm> wrote in
> news:fr-dncuiY-6DnnHcRVn-gA@rogers.com: 
> > If you do this, however, 
> > 
> > char * ty = "hello";
> > 
> > however ty points to a modifiable string.  Personnally I'd consider
> > that broken and rap the knuckles of any developer that proposed using
> > it but that's another issue.
> > 
> 
> Well, given that no const modifier was used in this example...
> 
> If you meant:

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

Robert

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.

On 2005-01-18, dereklai2k@yahoo.com.hk <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.

Well, that's certainly clear.

-- 
Grant Edwards                   grante             Yow!  Where do your SOCKS
                                  at               go when you lose them in
                               visi.com            th' WASHER?

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.

Moreover, from my personal feeling, sometimes not quoting is more clear
as the reader do not need to locate the answer.

On 2005-01-18, leonlai2k@yahoo.com <leonlai2k@yahoo.com> wrote:

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

Oh for pete's sake, the word is "you".

You're Welcome.

-- 
Grant Edwards                   grante             Yow!  for ARTIFICIAL
                                  at               FLAVORING!!
                               visi.com            

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.

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.

-- 
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
<radsett@junk.aeolusdevelopment.cm> wrote in comp.arch.embedded:

> In article <pan.2005.01.17.07.36.50.880000@westcontrol.removethis.com>, 
> david.nospam@westcontrol.removethis.com says...
> > 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).
> 
> I don't believe so.  AFAIR the meaning of const in C is (more or less) 
> "it is forbidden to write to this".  The compiler/linker is free to place 
> that whereever suits them. 
> 
> You may be thinking of strings like "hello" which are (again AFAIR) not 
> const.  But if declare something as 
> 
> const int u = 9;
> const char fg[] = "hello";
> 
> you get two items that are unwriteable and the compiler is free to place 
> them in readonly memory.
> 
> 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.

> however ty points to a modifiable string.  Personnally I'd consider that 
> broken and rap the knuckles of any developer that proposed using it but 
> that's another issue.
> 
> Robert

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?
http://www.eskimo.com/~scs/C-faq/q16.6.html

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

<dereklai2k@yahoo.com.hk> wrote in message 
news:1106015453.847168.81960@z14g2000cwz.googlegroups.com...
>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.

It would be easier for you to tell us than to write so many weasel words 
trying to avoid it.

Is the idea that we help you but you do not help us?

Please tell us the solution to the mystery, or give us an *exact* reference 
to where we can see what you've already given.