d...@yahoo.com.hk wrote:
> Sorry, actually I do not intend to not reveal the solution of this
> thread, as the solution is my very careless mistake and does not have a
> greal learning value.

You're like a broken record -- I think the most important feature of 
usenet is information sharing. Careless or not, if you don't share 
you're using a resource without giving back. That's freeloading.

Brett Foster

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.

On Sun, 16 Jan 2005 18:03:02 -0800, dereklai2k wrote:

> Sorry, actually I do not intend to not reveal the solution of this
> thread, as the solution is my very careless mistake and does not have a
> greal learning value.

You started a thread claiming to have found a bug in gcc-avr, and
apparently it was your own mistake.  Well, we all make mistakes - but we
don't all start off by accusing others and then refusing to acknowledge
the mistake.  Remember, these posts are archieved for the benifit of
future users - you have a responsibility to make it clear to current and
future readers that your problem was not caused by a bug in avr-gcc. 
Anything less is a grave disservice to the avr-gcc team, who have provided
you with an excellent set of tools, asking nothing in return but a bit of
respect.

The careless mistake is in the other thread. I have clarify the mistake
in this thread.

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

d...@yahoo.com.hk wrote:
> 
> The careless mistake is in the other thread. I have clarify the mistake
> in this thread.

You are continuing to annoy by failing to quote the material to
which you reply, and by refusing to expound what the mistake was. 
Vague references to other threads won't do.  The fact that you will
get no help later when you need it should induce you to reform.

You have seen my sig several times, so there is no longer any
excuse for refusing to quote.

-- 
"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 Mon, 17 Jan 2005 00:19:13 -0800, dereklai2k wrote:

> The careless mistake is in the other thread. I have clarify the mistake
> in this thread.

You have not clarified anything - you have merely made repeated claims
about clarifications, and about having made some silly mistake that you
refuse to expand on.  Lots of people come to newsgroups like this one
looking for help, only to find they have made a silly mistake - but maybe
they and others learn something new anyway.  A silly mistake for one
person might be a fundamental misunderstanding for another - that's why
it's important to share the information.

And we are all still waiting to hear your apology to the avr-gcc team for
your unfounded allogations.

On 2005-01-17, David <d...@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.

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

-- 
Grant Edwards                   grante             Yow!  Are you selling NYLON
                                  at               OIL WELLS?? If so, we can
                               visi.com            use TWO DOZEN!!

In article <p...@westcontrol.removethis.com>, 
d...@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";

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

R Adsett <r...@junk.aeolusdevelopment.cm> wrote in
news:f...@rogers.com: 

> In article
> <p...@westcontrol.removethis.com>, 
> d...@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. 

K&R second edition agress with you on this, although it does leave it up 
to the implementation as to what happens if you do attempt to modify a 
const.

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

const char * ty = "hello";

then, the pointer ty should be unmodifiable, whereas what it points at is 
free to be modified as I recall.

-- 
Richard