Bug found in GCC-AVR/ AVRStudio

This sounds more like an issue with the startup code. What happens if you declare it as const char instead?

Same problem exists. Actually I tried const char firstly, but GCC seemed to regard it as ram data.

AVR Studio 4.11 is now released and avaialble at

-- Best Regards, Ulf Samuelsson. Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Nordic AB.

Has also tried avrstudio 4.11 beta and the problem still exists.

I take it you want this variable to exist in program memory (ROM)?

-- Nicholas O. Lindan, Cleveland, Ohio Consulting Engineer: Electronics; Informatics; Photonics. Remove spaces etc. to reply: n o lindan at net com dot com psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

also does not bother to reveal a solution when found. Thus I recommend ignoring him.

My vote, too for a PLONK.

Let's give him an opportunity:

Please post a minimal example which does not behave. Compile the code and run

avr-objdump -D testfile.elf >testfile.dis

and post the output.

My feel is that this is an erroneous diagnosis of some other problem.

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

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

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.

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.

Not in my systems it isn't. I tell the linker to put const data in ROM along with the code.

gcc puts const data into seperate sections. The linker puts them into RAM vs. flash vs. whatever.

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 wrote in news: snipped-for-privacy@rogers.com:

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.

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.