On 2005-01-18, CBFalconer <c...@yahoo.com> wrote:
> d...@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.

I second the PLONK.

All in favor say "aye".

-- 
Grant Edwards                   grante             Yow!  Excuse me, but didn't
                                  at               I tell you there's NO HOPE
                               visi.com            for the survival of OFFSET
                                                   PRINTING?

On Mon, 17 Jan 2005 23:48:38 -0500, R Adsett
<r...@junk.aeolusdevelopment.cm> wrote in comp.arch.embedded:

> In article <v...@4ax.com>, 
> j...@spamcop.net says...
> > On Mon, 17 Jan 2005 13:25:33 -0500, R Adsett
> > <r...@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.

There's a very simple reason for this.  String literals were part of
the C language a good 15 years before the 1989 standard added the
'const' keyword, so that was 15 years worth of existing code that
would have been broken.

In fact, even in C++ where string literals do have the type array of
const char, they break the type system and allow the address of a
string literal to be assigned to a pointer to mutable char, just
because there is so much existing code.

> 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

Someday somebody will invent the perfect computer programming
language.  It might be you.  For sure, I've given up on the idea that
it will be me!

-- 
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 Tue, 18 Jan 2005 11:12:06 +0100, David
<d...@westcontrol.removethis.com> wrote in comp.arch.embedded:

> On Mon, 17 Jan 2005 21:23:33 -0600, Jack Klein wrote:
> 
> > On Mon, 17 Jan 2005 08:36:51 +0100, David
> > <d...@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 ?

Not unless there was a standard for C other than the original de facto
one, K&R 1 published in 1978.  Even that text stated that the result
of attempting to modify a string literal was undefined.

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

Yes, this code is perfectly legal, and it causes no problem with
implementations that put code into EPROM/flash/write-protected memory.
You can always assign a pointer to a more qualified (with const and/or
volatile) object with the address of a less qualified object of the
same type.  And if the compiler put 'i' in read-only memory it would
be seriously non-conforming.  Because:

 *((int *) p) = 100;

...is legal code and does what you expect.  You can cast away
"const-ness" as long as the object was not actually defined const.

Adding the const qualifier to the type pointed to by a pointer does
not mean it can actually only point to const objects.  It merely says
that you will not modify the object through the pointer.

If you cast away the const and attempt to modify the object, it is
well defined if the object is not const, undefined if it is.

> I suppose an avr compiler could get round this by using three-byte
> pointers, but that would be somewhat inefficient.
> 
> David

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

Jack Klein wrote:

>>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.
>>    
>>
>
>Yes, this code is perfectly legal, and it causes no problem with
>implementations that put code into EPROM/flash/write-protected memory.
>You can always assign a pointer to a more qualified (with const and/or
>volatile) object with the address of a less qualified object of the
>same type.  And if the compiler put 'i' in read-only memory it would
>be seriously non-conforming.  Because:
>
> *((int *) p) = 100;
>
>...is legal code and does what you expect.  You can cast away
>"const-ness" as long as the object was not actually defined const.
>
>Adding the const qualifier to the type pointed to by a pointer does
>not mean it can actually only point to const objects.  It merely says
>that you will not modify the object through the pointer.
>
>If you cast away the const and attempt to modify the object, it is
>well defined if the object is not const, undefined if it is.
>
>  
>
I am pretty sure ImageCraft's AVR compiler does what Jack is saying. 
Basically, we do "reasonable" without going thru extreme heroics.

>>I suppose an avr compiler could get round this by using three-byte
>>pointers, but that would be somewhat inefficient.
>>
>>    
>>
Make that EXTREMELY inefficient :-)

-- 
// richard
http://www.imagecraft.com

On Tue, 18 Jan 2005 20:31:42 -0600, Jack Klein wrote:

> On Tue, 18 Jan 2005 11:12:06 +0100, David
> <d...@westcontrol.removethis.com> wrote in comp.arch.embedded:
> 
>> 
>> 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 ?
> 
> Not unless there was a standard for C other than the original de facto
> one, K&R 1 published in 1978.  Even that text stated that the result
> of attempting to modify a string literal was undefined.
> 

OK - thanks for correcting me.

>> 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.
> 
> Yes, this code is perfectly legal, and it causes no problem with
> implementations that put code into EPROM/flash/write-protected memory.
> You can always assign a pointer to a more qualified (with const and/or
> volatile) object with the address of a less qualified object of the
> same type.  And if the compiler put 'i' in read-only memory it would
> be seriously non-conforming.  Because:
> 
>  *((int *) p) = 100;
> 
> ...is legal code and does what you expect.  You can cast away
> "const-ness" as long as the object was not actually defined const.
> 
> Adding the const qualifier to the type pointed to by a pointer does
> not mean it can actually only point to const objects.  It merely says
> that you will not modify the object through the pointer.
> 
> If you cast away the const and attempt to modify the object, it is
> well defined if the object is not const, undefined if it is.
> 

Yes, that's my understanding too.  But on an architecture like the AVR,
accessing data in flash and data in ram is done in different ways. 
Consider the following setup:

void outputConst(const int *p) { printf("%i", *p); }
const int c = 10;
int v = 20;
void testC(void) { outputConst(&c); }
void testV(void) { outputConst(&v); }

Assume these are in different files, or there is no global optomisation or
other tricks.  Both testC and testV are valid code, and should work fine. 
But if c is placed in flash and v in ram, then there is no way to
implement outputConst in a way that works for both of them.  That's why
placing const data in flash on an AVR is non-conforming.  ImageCraft,
whose compiler does place "const" in flash, makes no claims to the
contrary - they view it as a reasonable compromise that gives most users
the code they want in most cases, while keeping code neat and readable. 
gcc-avr uses macros and attributes for flash, so that their "const" is
standard, and IAR uses the extra non-standard keyword "flash".





>> I suppose an avr compiler could get round this by using three-byte
>> pointers, but that would be somewhat inefficient.
>> 
>> David

In article <1...@4ax.com>, 
j...@spamcop.net says...
> Someday somebody will invent the perfect computer programming
> language.  It might be you.  For sure, I've given up on the idea that
> it will be me!

Nah, I'd probably do something silly like re-invent APL.

Robert

On Tue, 18 Jan 2005 19:29:23 -0800, "Richard M."
<r...@imagecraft.com> wrote:

>Jack Klein wrote:
[...]
>>>I suppose an avr compiler could get round this by using three-byte
>>>pointers, but that would be somewhat inefficient.
>>>
>>>    
>>>
>Make that EXTREMELY inefficient :-)

Have you tried it?  I'm curious because I've used 8051 compilers that
have generic pointers, and the code produced is not unreasonable.  And
there have been cases where the capability would have been welcome.

I may try it someday, though I'm sure an implementor could do a better
job.  And an implementor could use them for functions like memcpy and
puts.

   enum memory_space {RAM, FLASH, EEPROM};
   typedef enum memory_space Memory_Space;
   typedef uint16_t  Address
   struct generic_ptr
   {
      Memory_Space   space;
      Address        adr;
   };
   typedef struct generic_ptr Generic_Ptr;

   extern Generic_Ptr GP_make(Memory_Space s, Address adr);
   extern void GP_write(Generic_Ptr p, void *src, size_t len);
   extern void GP_read(void *dest, Generic_Ptr p, size_t len);
   extern void GP_copy(Generic_Ptr d, Generic_Ptr s, size_t len);

Of course, this all assumes that pointers that did not need to be
generic would not be made generic.  Like the 8051 compilers.

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

R Adsett wrote:
> In article <1...@4ax.com>, 
> j...@spamcop.net says...
> 
>>Someday somebody will invent the perfect computer programming
>>language.  It might be you.  For sure, I've given up on the idea that
>>it will be me!
> 
> 
> Nah, I'd probably do something silly like re-invent APL.
> 
> Robert

Yep - the number 1 write-only language.

-- 

Tauno Voipio
tauno voipio (at) iki fi

Dave Hansen wrote:

>>Make that EXTREMELY inefficient :-)
>>    
>>
>
>Have you tried it?  I'm curious because I've used 8051 compilers that
>have generic pointers, and the code produced is not unreasonable.  And
>there have been cases where the capability would have been welcome.
>
>I may try it someday, though I'm sure an implementor could do a better
>job.  And an implementor could use them for functions like memcpy and
>puts.
>
>   enum memory_space {RAM, FLASH, EEPROM};
>   typedef enum memory_space Memory_Space;
>   typedef uint16_t  Address
>   struct generic_ptr
>   {
>      Memory_Space   space;
>      Address        adr;
>   };
>   typedef struct generic_ptr Generic_Ptr;
>
>   extern Generic_Ptr GP_make(Memory_Space s, Address adr);
>   extern void GP_write(Generic_Ptr p, void *src, size_t len);
>   extern void GP_read(void *dest, Generic_Ptr p, size_t len);
>   extern void GP_copy(Generic_Ptr d, Generic_Ptr s, size_t len);
>
>Of course, this all assumes that pointers that did not need to be
>generic would not be made generic.  Like the 8051 compilers.
>
>Regards,
>      
>                               -=Dave
>  
>
It's a thought. However, I suspect there are higher priority items that 
we can do for customers before this one. Once this problem is known, 
most customers know how to work around it. So it is in the enhancement 
bin, but not an urgent one...

-- 
// richard
http://www.imagecraft.com

I finally store these data into flash using functions in progmem.h,
rather than store them in sram.