Yahoo Groups archive
Thread
2006-02-10 by G B
I finally got my avr asm app converted to gnuarm c
and it compiles.
However, it does not like:
int is_any(unsigned char *, char);
const unsigned char string1[]={"abcdefgh"};
...
ch = 'd';
if(is_any(string1, ch)==0)....;
I had other const strings, and it gave me warnings as well.
Do we have to use const to ensure that the strings as constant
and put in flash rather than ram?
Thanks,
Glen2006-02-10 by Sean
Hello,
Using gnuarm with the following code:
int is_any(unsigned char *str, char ch)
{
unsigned char myCh;
while((myCh=*str++))
{
if (ch == myCh)
return ch;
}
return 0;
}
const unsigned char string1[]={"abcdefgh"};
int test()
{
char ch = 'd';
if(is_any(string1, ch)==0)
{
printf("Not there!");
return 1;
}
return 0;
}
returns this as a warning:
test.c: In function `test':
test.c:32: warning: passing arg 1 of `is_any' discards qualifiers from
pointer target type
this is because you're passing a "const uchar *" as a "uchar *"
param. Changing either the function to is_any(const unsigned char
*,char) or removing const from the string declaration removes this
warning, but it's only a warning, it won't effect the execution.
-- Sean
At 16:51 2/10/2006, you wrote:>I finally got my avr asm app converted to gnuarm c
>and it compiles.
>
>However, it does not like:
>int is_any(unsigned char *, char);
>
>const unsigned char string1[]={"abcdefgh"};
>
>...
> ch = 'd';
> if(is_any(string1, ch)==0)....;
>
>I had other const strings, and it gave me warnings as well.
>
>Do we have to use const to ensure that the strings as constant
>and put in flash rather than ram?
>
>Thanks,
>
>Glen2006-02-10 by David Hawkins
> returns this as a warning: > > test.c: In function `test': > test.c:32: warning: passing arg 1 of `is_any' discards qualifiers from > pointer target type > > this is because you're passing a "const uchar *" as a "uchar *" > param. Changing either the function to is_any(const unsigned char > *,char) or removing const from the string declaration removes this > warning, but it's only a warning, it won't effect the execution. It would be good programming practice to change the function to take a const char. This tells the compiler and user that the function does not modify what that argument points to. Dave
2006-02-11 by G B
Sean, Thanks. Does this mean the compiler does not 'move' strings like this into ram? So, I need not worry about the 'const' label? I have a huge font array that I want in flash of course. TIA Glen Sean wrote:
> test.c:32: warning: passing arg 1 of `is_any' discards qualifiers from > pointer target type > > this is because you're passing a "const uchar *" as a "uchar *" > param. Changing either the function to is_any(const unsigned char > *,char) or removing const from the string declaration removes this > warning, but it's only a warning, it won't effect the execution. > > -- Sean >
2006-02-11 by Sean
Strings literals are stored in flash and copied into RAM as part of the startup of the application (along with all other preinitialized variables). However to be safe it's better to explicitly declare anything you want to be in flash as const. If you didn't declare the array that you were using for is_any as a const then the string data would be copied from flash to ram at startup. If it is declared as const then it stays in flash and is referenced directly from there without a ram counterpart. -- Sean At 20:46 2/10/2006, you wrote:
>Sean, > >Thanks. Does this mean the compiler does not 'move' strings like this >into ram? So, I need not worry about the 'const' label? >I have a huge font array that I want in flash of course. > >TIA > >Glen > > >Sean wrote: > > test.c:32: warning: passing arg 1 of `is_any' discards qualifiers from > > pointer target type > > > > this is because you're passing a "const uchar *" as a "uchar *" > > param. Changing either the function to is_any(const unsigned char > > *,char) or removing const from the string declaration removes this > > warning, but it's only a warning, it won't effect the execution. > > > > -- Sean
2006-02-11 by Robert Adsett
At 09:03 PM 2/10/06 -0500, Sean wrote: >Strings literals are stored in flash and copied into RAM as part of the >startup of the application (along with all other preinitialized >variables). You might want to check your linker files. Although I believe it's possible to set up gcc to copy string literals to flash I know I've not got mine set up to do that. They stay in flash (I just checked with objdump and sure enough they are in the section that does not get copied out of flash) I suppose you could just try to write to a string literal and see if you can change it. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " -- Kelvin Throop, III http://www.aeolusdevelopment.com/
2006-02-11 by Tom Walsh
G B wrote: >Sean, > >Thanks. Does this mean the compiler does not 'move' strings like this >into ram? So, I need not worry about the 'const' label? >I have a huge font array that I want in flash of course. > > > Double check by looking in the listings file (.lst), not always is a const stored in the .rodata section. Sometimes, if you get warnings, it may mean to the compile that you intend on ignoring the const definition may intend to change it. Thus, it will take that implication and store in .data instead. The warning doesn't mean it will not put it into .rodata, but... I like my compiles clean, no warnings. Regards, TomW >TIA > >Glen > > >Sean wrote: > > >>test.c:32: warning: passing arg 1 of `is_any' discards qualifiers from >>pointer target type >> >>this is because you're passing a "const uchar *" as a "uchar *" >>param. Changing either the function to is_any(const unsigned char >>*,char) or removing const from the string declaration removes this >>warning, but it's only a warning, it won't effect the execution. >> >>-- Sean >> >> >> > > > > >Yahoo! Groups Links > > > > > > > > -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2006-02-11 by Guillermo Prandi
Hi, Sean. From tests I did with GCC 4.0.1, I came into the conclusion
that:
char* test1 = "TEST1"; <--- doesn't get copied to RAM
char test2[] = {'T','E','S','T','2'}; <--- does get copied to RAM.
i.e., omiting the const modifier is not enough to make strings be
copied to RAM. Strings declared with double quotes are considered
const whether we say so or not. There are options to explore besides
this. For instance, you can specify the section where you want your
variable placed (.text, .data, etc.); I did no tests with that.
Guille
--- In lpc2000@yahoogroups.com, Sean <embeddedrelated@...> wrote:
>
>
> Strings literals are stored in flash and copied into RAM as part of
the
> startup of the application (along with all other preinitialized
> variables). However to be safe it's better to explicitly declare
anything
> you want to be in flash as const.
>
> If you didn't declare the array that you were using for is_any as a
const
> then the string data would be copied from flash to ram at startup.
If it
> is declared as const then it stays in flash and is referenced
directly from
> there without a ram counterpart.
>
> -- Sean
>
> At 20:46 2/10/2006, you wrote:
> >Sean,
> >
> >Thanks. Does this mean the compiler does not 'move' strings like
this
> >into ram? So, I need not worry about the 'const' label?
> >I have a huge font array that I want in flash of course.
> >
> >TIA
> >
> >Glen
> >
> >
> >Sean wrote:
> > > test.c:32: warning: passing arg 1 of `is_any' discards
qualifiers from
> > > pointer target type
> > >
> > > this is because you're passing a "const uchar *" as a "uchar *"
> > > param. Changing either the function to is_any(const unsigned
char
> > > *,char) or removing const from the string declaration removes
this> > > warning, but it's only a warning, it won't effect the execution. > > > > > > -- Sean >
2006-02-11 by G B
That's the ticket! How can you tell the compiler to put the string in flash? Glen Guillermo Prandi wrote:
> Hi, Sean. From tests I did with GCC 4.0.1, I came into the conclusion
> that:
>
> char* test1 = "TEST1"; <--- doesn't get copied to RAM
> char test2[] = {'T','E','S','T','2'}; <--- does get copied to RAM.
>
> i.e., omiting the const modifier is not enough to make strings be
> copied to RAM. Strings declared with double quotes are considered
> const whether we say so or not. There are options to explore besides
> this. For instance, you can specify the section where you want your
> variable placed (.text, .data, etc.); I did no tests with that.
>
> Guille
>2006-02-11 by G B
oops! no listing file. I have map. how do I force a list (is this the assembler output?, and, is it 'fixed' by the linker to put REAL addresses in it?)? Thanks Glen Tom Walsh wrote:
> > Double check by looking in the listings file (.lst), not always is a > const stored in the .rodata section. Sometimes, if you get warnings, it > may mean to the compile that you intend on ignoring the const definition > may intend to change it. Thus, it will take that implication and store > in .data instead. The warning doesn't mean it will not put it into > .rodata, but... > > I like my compiles clean, no warnings. > > Regards, > > TomW
2006-02-11 by Guillermo Prandi
If you use 'const', they will stay in flash, rest assured.
This is my compile command for 'console.c' (not using thumb, just
ARM):
gcc -c -mcpu=arm7tdmi -I. -gdwarf-2 -DREENTRANT_SYSCALLS_PROVIDED
-DROM_RUN -DGCC_ARM7 -I ./include -O2 -Wall -Wcast-align
-Wimplicit -Wwrite-strings -Wpointer-arith -Wswitch -Wreturn-type
-Wunused -Wshadow -Wa,-adhlns=lib/console.lst
-fmerge-constants -IARG -IARG/include -MD -MP
-MF .dep/console.o.d -Wstrict-prototypes -Wmissing-declarations
-Wmissing-prototypes -std=gnu99 lib/console.c -o lib/console.o
And this is the linker command for the 'project' executable:
gcc -mcpu=arm7tdmi -I. -gdwarf-2 -DREENTRANT_SYSCALLS_PROVIDED
-DROM_RUN -DGCC_ARM7 -I ./include -O2 -Wall -Wcast-align
-Wimplicit -Wwrite-strings -Wpointer-arith -Wswitch
-Wreturn-type -Wunused -Wshadow -Wa,-adhlns=build/crt0.lst
-fmerge-constants -MD -MP -MF .dep/project.elf.d
build/crt0.o lib/console.o --output project.elf -nostartfiles
-Wl,-Map=project.map,--cref -lc -lm -lc -lgcc
-Tbuild/LPC2138-ROM.ld
The -Map=project.map option will output the map file. The --cref
addition will output the final assembler listing (.lss). I don't
recall which of these linker options will give you the project.sym
file. In this file (.sym) you will be able to see whether your
variable will reside in flash or in RAM: flash addresses are below
0x00080000, whilst RAM addresses will be between 0x4000000 and
0x40007fff. Also, a letter before the symbol name will give you the
name of the section where they will be placed (t=.text, d=.data,
b=.bss). For example, these are tables that will reside in flash
(.text):
0001ca4c t hex
0001ca60 t leds.1409
0001ca78 t badptr.1408
0001ca88 t SectorsByCPU
0001caa0 t LPC2138sectors
0001cbf0 t cOffPat
0001cbfc t LED_Bits
These are tables that will be copied to RAM at system startup (.data):
40000014 d sGPSMaxWait
40000018 d sGPSMinSats
4000001c d sGPSMinData
40000020 d sGPSOffDuty
40000024 d sGPSOnDuty
Finally, these are variables that will be zero-filled and reside in
RAM from start (.bss):
40001e00 b sNextAction
40001e04 b sMainShutDown
40001e08 b sMainThreadHandle
The t, d, and b flags come also in uppercase flavor, although I don't
know what is the difference between t and T, d and D or b and B.
All this is provided you start from 'standard' crt0.asm and .ld
scripts, like those from the WinARM or FreeRTOS examples for gcc.
Guille
--- In lpc2000@yahoogroups.com, G B <microsys@...> wrote:
>
> That's the ticket!
>
> How can you tell the compiler to put the string in flash?
>
> Glen
>
>
> Guillermo Prandi wrote:
> > Hi, Sean. From tests I did with GCC 4.0.1, I came into the
conclusion
> > that:
> >
> > char* test1 = "TEST1"; <--- doesn't get copied to RAM
> > char test2[] = {'T','E','S','T','2'}; <--- does get copied to
RAM.
> >
> > i.e., omiting the const modifier is not enough to make strings be
> > copied to RAM. Strings declared with double quotes are considered
> > const whether we say so or not. There are options to explore
besides
> > this. For instance, you can specify the section where you want
your > > variable placed (.text, .data, etc.); I did no tests with that. > > > > Guille > > >
2006-02-12 by Tom Walsh
Guillermo Prandi wrote:
>If you use 'const', they will stay in flash, rest assured.
>
>
>
Ah, thanks, so all I have to do is assume that if I put "const" on the
structure tag then it will go into Flash... Hmmm....
I prefer to check those things out, like looking inside the lst file on
occasion and surveying what the compiler is doing.
Regards,
TomW
>This is my compile command for 'console.c' (not using thumb, just
>ARM):
>
>gcc -c -mcpu=arm7tdmi -I. -gdwarf-2 -DREENTRANT_SYSCALLS_PROVIDED
>-DROM_RUN -DGCC_ARM7 -I ./include -O2 -Wall -Wcast-align
>-Wimplicit -Wwrite-strings -Wpointer-arith -Wswitch -Wreturn-type
>-Wunused -Wshadow -Wa,-adhlns=lib/console.lst
>-fmerge-constants -IARG -IARG/include -MD -MP
>-MF .dep/console.o.d -Wstrict-prototypes -Wmissing-declarations
>-Wmissing-prototypes -std=gnu99 lib/console.c -o lib/console.o
>
>And this is the linker command for the 'project' executable:
>
>gcc -mcpu=arm7tdmi -I. -gdwarf-2 -DREENTRANT_SYSCALLS_PROVIDED
>-DROM_RUN -DGCC_ARM7 -I ./include -O2 -Wall -Wcast-align
>-Wimplicit -Wwrite-strings -Wpointer-arith -Wswitch
>-Wreturn-type -Wunused -Wshadow -Wa,-adhlns=build/crt0.lst
>-fmerge-constants -MD -MP -MF .dep/project.elf.d
>build/crt0.o lib/console.o --output project.elf -nostartfiles
>-Wl,-Map=project.map,--cref -lc -lm -lc -lgcc
>-Tbuild/LPC2138-ROM.ld
>
>The -Map=project.map option will output the map file. The --cref
>addition will output the final assembler listing (.lss). I don't
>recall which of these linker options will give you the project.sym
>file. In this file (.sym) you will be able to see whether your
>variable will reside in flash or in RAM: flash addresses are below
>0x00080000, whilst RAM addresses will be between 0x4000000 and
>0x40007fff. Also, a letter before the symbol name will give you the
>name of the section where they will be placed (t=.text, d=.data,
>b=.bss). For example, these are tables that will reside in flash
>(.text):
>
>0001ca4c t hex
>0001ca60 t leds.1409
>0001ca78 t badptr.1408
>0001ca88 t SectorsByCPU
>0001caa0 t LPC2138sectors
>0001cbf0 t cOffPat
>0001cbfc t LED_Bits
>
>These are tables that will be copied to RAM at system startup (.data):
>
>40000014 d sGPSMaxWait
>40000018 d sGPSMinSats
>4000001c d sGPSMinData
>40000020 d sGPSOffDuty
>40000024 d sGPSOnDuty
>
>Finally, these are variables that will be zero-filled and reside in
>RAM from start (.bss):
>
>40001e00 b sNextAction
>40001e04 b sMainShutDown
>40001e08 b sMainThreadHandle
>
>
>The t, d, and b flags come also in uppercase flavor, although I don't
>know what is the difference between t and T, d and D or b and B.
>
>All this is provided you start from 'standard' crt0.asm and .ld
>scripts, like those from the WinARM or FreeRTOS examples for gcc.
>
>Guille
>
>--- In lpc2000@yahoogroups.com, G B <microsys@...> wrote:
>
>
>>That's the ticket!
>>
>>How can you tell the compiler to put the string in flash?
>>
>>Glen
>>
>>
>>Guillermo Prandi wrote:
>>
>>
>>>Hi, Sean. From tests I did with GCC 4.0.1, I came into the
>>>
>>>
>conclusion
>
>
>>>that:
>>>
>>>char* test1 = "TEST1"; <--- doesn't get copied to RAM
>>>char test2[] = {'T','E','S','T','2'}; <--- does get copied to
>>>
>>>
>RAM.
>
>
>>>i.e., omiting the const modifier is not enough to make strings be
>>>copied to RAM. Strings declared with double quotes are considered
>>>const whether we say so or not. There are options to explore
>>>
>>>
>besides
>
>
>>>this. For instance, you can specify the section where you want
>>>
>>>
>your
>
>
>>>variable placed (.text, .data, etc.); I did no tests with that.
>>>
>>>Guille
>>>
>>>
>>>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------2006-02-12 by Tom Walsh
G B wrote: >oops! no listing file. I have map. >how do I force a list (is this the assembler output?, and, is >it 'fixed' by the linker to put REAL addresses in it?)? > > > Listings files are produced by the assembler, gas, try 'info gas' to get a complete list of options. What you are looking for is the command line options (-Wa). In short, add this to your CFLAGS for the gcc invokation line: -Wa,alh$(<:.c=.lst) When gcc sees the "-Wa," it will pass the remainder to the assembler as options to it, producing an lst file. There are other options you may find interesting.. TomW >Thanks > >Glen > > >Tom Walsh wrote: > > >>Double check by looking in the listings file (.lst), not always is a >>const stored in the .rodata section. Sometimes, if you get warnings, it >>may mean to the compile that you intend on ignoring the const definition >>may intend to change it. Thus, it will take that implication and store >>in .data instead. The warning doesn't mean it will not put it into >>.rodata, but... >> >>I like my compiles clean, no warnings. >> >>Regards, >> >>TomW >> >> > > > > >Yahoo! Groups Links > > > > > > > > > -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2006-02-12 by Sean
I may be doing things wrong, but my tests show something different. I'm
also using GCC 3.4.3.
I assume that something mapped as .data will be copied to ram, .rodata will
not be?
Here are my results:
char * test1p = "test 1 pointer"; // .data
char test1b[] = "test 1 bracket"; // .data
char test2b[] = {'t','e','s','t',' ','2','
','b','r','a','c','k','e','t',0}; // .data
const char * test3p = "test 3 pointer"; // .data
const char test3b[] = "test 3 bracket"; // .rodata
char const * test4p = "test 4 pointer"; // .data
char const test4b[] = "test 4 bracket"; // .rodata
char * const test5p = "test 5 pointer"; // .rodata
char const test5b[] = "test 5 bracket"; // .rodata
const char const * test6p = "test 6 pointer"; // .data
const char const test6b[] = "test 6 bracket"; // .rodata
const char const test7b[] = "test 7 bracket"; // .rodata
const char * const test7p = "test 7 pointer"; // .rodata
char const const test8b[] = "test 8 bracket"; // .rodata
char const * const test8p = "test 8 pointer"; // .rodata
const char const const test9b[] = "test 9 bracket"; // .rodata
const char const * const test9p = "test 9 pointer"; // .rodata
Note that I made a dummy function call that read from all of these arrays.
I'm confused with test3,4 and test1. Both test1s are mapped to data;
however test3,4p are mapped to data, but test3,4b are mapped to rodata.
Most of that makes sense, and most of the following does:
test1p[0] = 'f'; // .data; ok
test1b[0] = 'o'; // .data; ok
test2b[0] = 'o'; // .data; ok
test3p[0] = 'b'; // .data; nok
test3b[0] = 'a'; // .rodata; nok
test4p[0] = 'r'; // .data; nok
test4b[0] = 'f'; // .data; nok
test5p[0] = 'o'; // .rodata; ok ****
test5b[0] = 'o'; // .rodata; nok
test6p[0] = 'o'; // .data; nok
test6b[0] = 'o'; // .rodata; nok
test7p[0] = 'b'; // .rodata; nok
test7b[0] = 'b'; // .rodata; nok
test8p[0] = 'a'; // .rodata; nok
test8b[0] = 'a'; // .rodata; nok
test9p[0] = 'r'; // .rodata; nok
test9b[0] = 'r'; // .rodata; nok
Except for test5p -- it's mapped to .rodata yet the compiler allows me to
try to change it, while it won't let me change test5b??
-- Sean
At 06:38 2/11/2006, you wrote:>Hi, Sean. From tests I did with GCC 4.0.1, I came into the conclusion
>that:
>
>char* test1 = "TEST1"; <--- doesn't get copied to RAM
>char test2[] = {'T','E','S','T','2'}; <--- does get copied to RAM.
>
>i.e., omiting the const modifier is not enough to make strings be
>copied to RAM. Strings declared with double quotes are considered
>const whether we say so or not. There are options to explore besides
>this. For instance, you can specify the section where you want your
>variable placed (.text, .data, etc.); I did no tests with that.
>
>Guille
>
>--- In lpc2000@yahoogroups.com, Sean <embeddedrelated@...> wrote:
> >
> >
> > Strings literals are stored in flash and copied into RAM as part of
>the
> > startup of the application (along with all other preinitialized
> > variables). However to be safe it's better to explicitly declare
>anything
> > you want to be in flash as const.
> >
> > If you didn't declare the array that you were using for is_any as a
>const
> > then the string data would be copied from flash to ram at startup.
>If it
> > is declared as const then it stays in flash and is referenced
>directly from
> > there without a ram counterpart.
> >
> > -- Sean
> >
> > At 20:46 2/10/2006, you wrote:
> > >Sean,
> > >
> > >Thanks. Does this mean the compiler does not 'move' strings like
>this
> > >into ram? So, I need not worry about the 'const' label?
> > >I have a huge font array that I want in flash of course.
> > >
> > >TIA
> > >
> > >Glen
> > >
> > >
> > >Sean wrote:
> > > > test.c:32: warning: passing arg 1 of `is_any' discards
>qualifiers from
> > > > pointer target type
> > > >
> > > > this is because you're passing a "const uchar *" as a "uchar *"
> > > > param. Changing either the function to is_any(const unsigned
>char
> > > > *,char) or removing const from the string declaration removes
>this
> > > > warning, but it's only a warning, it won't effect the execution.
> > > >
> > > > -- Sean
> >
>
>
>
>
>
>
>SPONSORED LINKS
><http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=mfaAujKZXA2Z_vxre9sGnQ>Microcontrollers
><http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=9jjd2D3GOLIESVQssLmLsA>Microprocessor
><http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=OMnZuqMZX95mgutt4B-tDw>Intel
>microprocessors
><http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s=95&.sig=Malspbd0T4Rq3M4Q0nHrfw>Pic
>microcontrollers
>
>
>----------
>YAHOO! GROUPS LINKS
>
> * Visit your group "<http://groups.yahoo.com/group/lpc2000>lpc2000"
> on the web.
> *
> * To unsubscribe from this group, send an email to:
> *
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>lpc2000-unsubscribe@yahoogroups.com
>
> *
> * Your use of Yahoo! Groups is subject to the
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
>
>----------2006-02-12 by Clyde Stubbs
On Sun, Feb 12, 2006 at 05:11:07PM -0500, Sean wrote: > > char * const test5p = "test 5 pointer"; // .rodata > test5p[0] = 'o'; // .rodata; ok **** > Except for test5p -- it's mapped to .rodata yet the compiler allows me to > try to change it, while it won't let me change test5b?? the pointer variable test5p is mapped to .rodata, but what it points to is not. Your assignment is not changing test5p, just the contents of the memory that it points to, which is a string literal, with a type of "char *", NOT "const char *". In the case of: > char const test5b[] = "test 5 bracket" there is no pointer, just an array with an initializer. Clyde -- Clyde Stubbs | HI-TECH Software Email: clyde@... | Phone Fax WWW: http://www.htsoft.com/ | USA: (408) 490 2885 (408) 490 2885 PGP: finger clyde@... | AUS: +61 7 3722 7777 +61 7 3722 7778 --------------------------------------------------------------------------- HI-TECH C: compiling the real world.
2006-02-13 by George M. Gallant, Jr.
I am new to the LPC series and having problems with gcc-3.4.3. When
implementing
a primitive printf routine I get random behavior on detecting the '\n'
and outputting
a '\r'. With optimization set to O2 I get random results. With
optimizing turned off
it works all the time.
Environment: Linux Fedora Core 4
gcc-3.4.3
Olimex LPC-H2214 connected via USB
George
On Mon, 2006-02-13 at 08:53 +1000, Clyde Stubbs wrote:
> On Sun, Feb 12, 2006 at 05:11:07PM -0500, Sean wrote:
> >
> > char * const test5p = "test 5 pointer"; // .rodata
>
> > test5p[0] = 'o'; // .rodata; ok ****
>
> > Except for test5p -- it's mapped to .rodata yet the compiler allows
> me to
> > try to change it, while it won't let me change test5b??
>
> the pointer variable test5p is mapped to .rodata, but what it points
> to
> is not. Your assignment is not changing test5p, just the contents of
> the memory that it points to, which is a string literal, with a type
> of "char *", NOT "const char *".
>
> In the case of:
>
> > char const test5b[] = "test 5 bracket"
>
> there is no pointer, just an array with an initializer.
>
> Clyde
>
> --
> Clyde Stubbs | HI-TECH Software
> Email: clyde@... | Phone Fax
> WWW: http://www.htsoft.com/ | USA: (408) 490 2885 (408) 490 2885
> PGP: finger clyde@... | AUS: +61 7 3722 7777 +61 7 3722
> 7778
> ---------------------------------------------------------------------------
> HI-TECH C: compiling the real world.
>
>
>
> SPONSORED LINKS
>
> Microcontrollers
> Microprocessor
> Intel microprocessors
> Pic microcontrollers
>
>
>
> ______________________________________________________________________
> YAHOO! GROUPS LINKS
>
>
> 1. Visit your group "lpc2000" on the web.
>
> 2. To unsubscribe from this group, send an email to:
> lpc2000-unsubscribe@yahoogroups.com
>
> 3. Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
>
>
>
> ______________________________________________________________________
>
>
[Non-text portions of this message have been removed]