Yahoo Groups archive
Thread
2005-10-17 by Guillermo Prandi
Hi! Has anybody found this? I'm using gcc 4.01 (latest WinARM) and I'm
compiling for LPC2138 (ARM7). If I use this kind of stuff, constants
don't get to the HEX file:
char *c = "Hello";
or
my_func("Hello");
However, if I use a built-in function like printf or puts, they do!:
printf("Hello");
This only happens with -On, where n != 0.
Guille2005-10-17 by Robert Adsett
At 11:08 PM 10/17/05 +0000, Guillermo Prandi wrote:
>Hi! Has anybody found this? I'm using gcc 4.01 (latest WinARM) and I'm
>compiling for LPC2138 (ARM7). If I use this kind of stuff, constants
>don't get to the HEX file:
It sounds like a problem with your startup code.
>char *c = "Hello";
This string, for instance needs to be copied to RAM since your declaration
indicates it's modifiable.
>or
>
>my_func("Hello");
As will this if my_func is prototyped as void my_func (char *)
I think that's the case.
>However, if I use a built-in function like printf or puts, they do!:
>
>printf("Hello");
This however can point to the string in flash since printf expects a const
string.
The prototype is something like
int printf( const char *, ...);
Question: Does the problem disappear if you declare the first case as
const char *c = "Hello";
and prototype the function in the second as
void my_func( const char *);
>This only happens with -On, where n != 0.
I'd be really confident that was the problem, except I don't see how this
final statement fits in.
Still the const/non-const nature of the two cases cries out as being
critical. Maybe you are writing over the strings in RAM?
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/2005-10-18 by Guillermo Prandi
I too gave a suspicious look at the startup code. But the thing is,
in order to copy the modifiable data to RAM it must be in the ROM in
the first place! It doesn't show in the lst file, whilst puts()
parameters do.
I tried giving a const to the function's declaration, with no luck.
However, I narrowed down the problem to auto-inlining: if I move the
do_something() function to another source (I was testing with an
empty body on the function!), the strings do show in the .data. This
kinda makes sense, since the compiler realized that there was no
point for that constant to be in the code in the first place. What do
not makes much sense (but works well somehow) is:
char d[20];
char* c = "AAAAAAAAAAAAAAAAA";
d[0] = *(c++);
d[1] = *(c++);
d[2] = *(c++);
d[3] = *(c++);
Here there's some weird optimization choices: instead of storing a
number of A's and copying them without hesitation, the compiler
*knows* they're all A's, so it loads an A in r2 and repeats it along d
[n]... :P If I change "AAAAAAA..." for "ABCDEF....".... it changes an
A in r2, a D in r3, stores them in d[0],d[3], then performs ADD r2,
r2, #2 and SUB r3, r3, #2 and stores r2 and r3 in d[1], d[2].
WTF!!!!!!!
OK, then it works. Oddly, but works. It's my fault for making so
small test cases.
Guille
--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...>
wrote:
>
> At 11:08 PM 10/17/05 +0000, Guillermo Prandi wrote:
> >Hi! Has anybody found this? I'm using gcc 4.01 (latest WinARM) and
I'm
> >compiling for LPC2138 (ARM7). If I use this kind of stuff,
constants
> >don't get to the HEX file:
>
> It sounds like a problem with your startup code.
>
>
> >char *c = "Hello";
>
>
> This string, for instance needs to be copied to RAM since your
declaration
> indicates it's modifiable.
>
>
> >or
> >
> >my_func("Hello");
>
>
> As will this if my_func is prototyped as void my_func (char *)
> I think that's the case.
>
>
> >However, if I use a built-in function like printf or puts, they
do!:
> >
> >printf("Hello");
>
>
> This however can point to the string in flash since printf expects
a const
> string.
>
> The prototype is something like
>
> int printf( const char *, ...);
>
>
> Question: Does the problem disappear if you declare the first case
as
>
> const char *c = "Hello";
>
> and prototype the function in the second as
>
> void my_func( const char *);
>
>
>
>
> >This only happens with -On, where n != 0.
>
>
> I'd be really confident that was the problem, except I don't see
how this
> final statement fits in.
>
> Still the const/non-const nature of the two cases cries out as
being
> critical. Maybe you are writing over the strings in RAM?
>
> 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/ >
2005-10-18 by embeddedjanitor
--- In lpc2000@yahoogroups.com, "Guillermo Prandi" <yahoo.messenger@m
...> wrote:
>
> I too gave a suspicious look at the startup code. But the thing is,
> in order to copy the modifiable data to RAM it must be in the ROM in
> the first place! It doesn't show in the lst file, whilst puts()
> parameters do.
They will be in a different area.
A constant string will be on the rommable constants area (.rodata in
GNU talk).
A modifiable string will be in the data initialisation section (.data
in GNU talk). This is rommed, but is copied into RAM for the
execution.
>
> I tried giving a const to the function's declaration, with no luck.
No luck expected :-). consting a function just says that the function
will not try to modify the string that it is passed. It does not
modify the placement of the string.
> However, I narrowed down the problem to auto-inlining: if I move the
> do_something() function to another source (I was testing with an
> empty body on the function!), the strings do show in the .data. This
> kinda makes sense, since the compiler realized that there was no
> point for that constant to be in the code in the first place. What
do
> not makes much sense (but works well somehow) is:
>
> char d[20];
> char* c = "AAAAAAAAAAAAAAAAA";
>
> d[0] = *(c++);
> d[1] = *(c++);
> d[2] = *(c++);
> d[3] = *(c++);
>
> Here there's some weird optimization choices: instead of storing a
> number of A's and copying them without hesitation, the compiler
> *knows* they're all A's, so it loads an A in r2 and repeats it along
d
> [n]... :P If I change "AAAAAAA..." for "ABCDEF....".... it changes
an
> A in r2, a D in r3, stores them in d[0],d[3], then performs ADD r2,
> r2, #2 and SUB r3, r3, #2 and stores r2 and r3 in d[1], d[2].
> WTF!!!!!!!
The compiler writer sure is on a high caffiene diet! Pretty clever!
However, even if you'd used and arbitrary string, I'd expect it to
work and here's why. The string is held in const, but gets copied into
the d[] array by your code. Therefore your code is more-or-less doing
what startup code should do.
>
> OK, then it works. Oddly, but works. It's my fault for making so
> small test cases.
>
> Guille
>
>
> --- In lpc2000@...m, Robert Adsett <subscriptions@a...>
> wrote:
> >
> > At 11:08 PM 10/17/05 +0000, Guillermo Prandi wrote:
> > >Hi! Has anybody found this? I'm using gcc 4.01 (latest WinARM)
and
> I'm
> > >compiling for LPC2138 (ARM7). If I use this kind of stuff,
> constants
> > >don't get to the HEX file:
> >
> > It sounds like a problem with your startup code.
> >
> >
> > >char *c = "Hello";
> >
> >
> > This string, for instance needs to be copied to RAM since your
> declaration
> > indicates it's modifiable.
> >
> >
> > >or
> > >
> > >my_func("Hello");
> >
> >
> > As will this if my_func is prototyped as void my_func (char *)
> > I think that's the case.
> >
> >
> > >However, if I use a built-in function like printf or puts, they
> do!:
> > >
> > >printf("Hello");
> >
> >
> > This however can point to the string in flash since printf expects
> a const
> > string.
> >
> > The prototype is something like
> >
> > int printf( const char *, ...);
> >
> >
> > Question: Does the problem disappear if you declare the first
case > as > > > > const char *c = "Hello"; > > > > and prototype the function in the second as > > > > void my_func( const char *); > > > > > > > > > > >This only happens with -On, where n != 0. > > > > > > I'd be really confident that was the problem, except I don't see > how this > > final statement fits in. > > > > Still the const/non-const nature of the two cases cries out as > being > > critical. Maybe you are writing over the strings in RAM? > > > > 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/ > > >
2005-10-18 by Robert Adsett
At 01:51 AM 10/18/05 +0000, embeddedjanitor wrote:
>--- In lpc2000@yahoogroups.com, "Guillermo Prandi" <yahoo.messenger@m
>...> wrote:
> >
> > I too gave a suspicious look at the startup code. But the thing is,
> > in order to copy the modifiable data to RAM it must be in the ROM in
> > the first place! It doesn't show in the lst file, whilst puts()
> > parameters do.
>
>They will be in a different area.
Good point.
>A constant string will be on the rommable constants area (.rodata in
>GNU talk).
>
>A modifiable string will be in the data initialisation section (.data
>in GNU talk). This is rommed, but is copied into RAM for the
>execution.
>
> >
> > I tried giving a const to the function's declaration, with no luck.
>
>No luck expected :-). consting a function just says that the function
>will not try to modify the string that it is passed. It does not
>modify the placement of the string.
But it will make a difference in this case.
Case 1:
void myfun( char *);
myfun("test");
In this case we have a pointer to a modifiable string and therefore in ram.
Case 2:
void myfun( const char *)
myfun("test");
In this case we have a pointer to a non modifiable string and which can be
in flash. If this isn't true then printf wouldn't work given your above
and the OP has already stated that
printf("test");
works.
In the third case
void myfun( const char *);
void myfun2( char *);
char * f = "test";
myfun(f);
myfun2(f);
The source is the same and whether the argument is const makes no difference.
I think your diagnosis is likely right unless Case 2 above behaves
differently then printf. If it does something else is going on.
> > However, I narrowed down the problem to auto-inlining: if I move the
> > do_something() function to another source (I was testing with an
> > empty body on the function!), the strings do show in the .data. This
> > kinda makes sense, since the compiler realized that there was no
> > point for that constant to be in the code in the first place. What
Um, well yeah, with
static void myfunc( const char *)
{
}
func()
{
myfunc("test");
}
the compiler could quite legitimately optimize myfunc out of
existence. Even if it wasn't declared as a static function the compiler
could optimize the call away and leave the hook for any external callers. I
was sort of assuming you actually did something with the string, otherwise
how would you notice? Checking for a Copyright in the image maybe?
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/2005-10-18 by Tom Walsh
Guillermo Prandi wrote: >I too gave a suspicious look at the startup code. But the thing is, >in order to copy the modifiable data to RAM it must be in the ROM in >the first place! It doesn't show in the lst file, whilst puts() >parameters do. > >I tried giving a const to the function's declaration, with no luck. >However, I narrowed down the problem to auto-inlining: if I move the >do_something() function to another source (I was testing with an >empty body on the function!), the strings do show in the .data. This >kinda makes sense, since the compiler realized that there was no >point for that constant to be in the code in the first place. What do >not makes much sense (but works well somehow) is: > > > Well, there is always objdump: 'arm-elf-objdump -d -S -x -s <filename>.o' BTW, objdump not only works for object files but it also works quite nicely on elf files as well so you can see what your linker + ld script was up to... That'll get you started, then 'man nm' and 'man objdump', pretty powerfull tools to drill down inside various file formats. Also, by using them, you can get a good education on just what it is that your compiler does and where it is deciding to put things (which Sections). TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-10-18 by Sten
Hello,
why you do you declare a string in that way?
char * f = "Hello";
'char* f' declares only a pointer to something. In this declaration
"Hello" should be treated as constant char array by the compiler. Does
the compiler complains about assigning const to non-const if you turn on
-Wall???
Correct way to declare a pre-defined char array containing "Hello" would be:
char f[] = "Hello";
That's a different! May the first line result in some confusions in the
compiler?!?
Sten
Robert Adsett wrote:
> At 01:51 AM 10/18/05 +0000, embeddedjanitor wrote:
>
>>--- In lpc2000@yahoogroups.com, "Guillermo Prandi" <yahoo.messenger@m
>>...> wrote:
>>
>>>I too gave a suspicious look at the startup code. But the thing is,
>>>in order to copy the modifiable data to RAM it must be in the ROM in
>>>the first place! It doesn't show in the lst file, whilst puts()
>>>parameters do.
>>
>>They will be in a different area.
>
>
> Good point.
>
>
>
>>A constant string will be on the rommable constants area (.rodata in
>>GNU talk).
>>
>>A modifiable string will be in the data initialisation section (.data
>>in GNU talk). This is rommed, but is copied into RAM for the
>>execution.
>>
>>
>>>I tried giving a const to the function's declaration, with no luck.
>>
>>No luck expected :-). consting a function just says that the function
>>will not try to modify the string that it is passed. It does not
>>modify the placement of the string.
>
>
> But it will make a difference in this case.
>
> Case 1:
> void myfun( char *);
>
> myfun("test");
>
> In this case we have a pointer to a modifiable string and therefore in ram.
>
> Case 2:
>
> void myfun( const char *)
>
> myfun("test");
>
> In this case we have a pointer to a non modifiable string and which can be
> in flash. If this isn't true then printf wouldn't work given your above
> and the OP has already stated that
>
> printf("test");
>
> works.
>
> In the third case
>
> void myfun( const char *);
> void myfun2( char *);
> char * f = "test";
>
> myfun(f);
> myfun2(f);
>
> The source is the same and whether the argument is const makes no difference.
>
> I think your diagnosis is likely right unless Case 2 above behaves
> differently then printf. If it does something else is going on.
>
>
>>>However, I narrowed down the problem to auto-inlining: if I move the
>>>do_something() function to another source (I was testing with an
>>>empty body on the function!), the strings do show in the .data. This
>>>kinda makes sense, since the compiler realized that there was no
>>>point for that constant to be in the code in the first place. What
>
>
> Um, well yeah, with
>
> static void myfunc( const char *)
> {
> }
>
> func()
> {
> myfunc("test");
> }
>
> the compiler could quite legitimately optimize myfunc out of
> existence. Even if it wasn't declared as a static function the compiler
> could optimize the call away and leave the hook for any external callers. I
> was sort of assuming you actually did something with the string, otherwise
> how would you notice? Checking for a Copyright in the image maybe?
>
> 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/
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
--
/************************************************
Do you need a tiny and efficient real time
operating system (RTOS) with a preemtive
multitasking for LPC2000 or AT91SAM7?
http://nanortos.net-attack.de/
Or some open-source tools and code for LPC2000?
http://www.net-attack.de/
************************************************/2005-10-18 by Guillermo Prandi
Robert Adsett said:
> the compiler could quite legitimately optimize myfunc out of
> existence. Even if it wasn't declared as a static function the
compiler
> could optimize the call away and leave the hook for any external
callers. I
> was sort of assuming you actually did something with the string,
otherwise
> how would you notice? Checking for a Copyright in the image maybe?
>
> Robert
Sort of; when I start working with a new compiler/environment I go in
little steps. I did a small test and I was amazed I didn't see my
string in the image. Then I came up with these tests and didn't
expect the optimizer to be so aggresive.
Of course it is not a matter of const or not, since non-constant
predefined strings must first be placed in ROM in order to be copied
to RAM on startup. I was looking directly at binary the image, which
must hold both kinds of string.
Tom Walsh said:
> Well, there is always objdump: 'arm-elf-objdump -d -S -x -s
<filename>.o'
Thanks, Tom... I was looking at the .lst, .lss and .hex files, which
are quite similar. ;)
Sten says:
> why you do you declare a string in that way?
> char * f = "Hello";
It is indeed different to declare the string this way. With the above
method I could do strange things like:
char * n = c;
*(c++) = 'P';
printf("%s-%s",n,c);
>>> Pello-ello
Of course it is not what I intended (I'd try to avoid such
programming methods whenever possible). I just did it that way
because I learned it that way so many years ago and now it's an habit.
And no, it was not the compiler that was confused; it was me. :)
Guille2005-10-18 by Robert Adsett
At 10:14 AM 10/18/05 +0200, Sten wrote: >why you do you declare a string in that way? > > char * f = "Hello"; > >'char* f' declares only a pointer to something. In this declaration >"Hello" should be treated as constant char array by the compiler. Does >the compiler complains about assigning const to non-const if you turn on >-Wall??? Actually due to historical reasons it "Hello" doesn't get treated as a constant char array type. I'd prefer it that way but... Some implementations though will treat "hello" as a constant string in which case the pointer type and what it points to would be in conflict. I don't think the standard allows that but I don't know and I certainly don't know if any newer compilers do that. I do know that some pre-standard compilers would put the string in a constant area and that would cause some problems for programs that assumed they were modifiable. >Correct way to declare a pre-defined char array containing "Hello" would be: > > char f[] = "Hello"; > >That's a different! May the first line result in some confusions in the >compiler?!? Not if it's standards compliant. That doesn't mean it's impossible but it would be a pretty big point to mess up. Either form is 'correct' . Which one you choose is a matter of choice, style and the specific circumstance. Personally I would rarely use either one without a const qualifier. 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/
2005-10-18 by Guillermo Prandi
Actually: char *f = "Hello"; Left "Hello" in the ROM area. Whilst: char f[] = "Hello"; Left "Hello" in the RAM area (after copying from ROM, of course). Guille --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote: > > At 10:14 AM 10/18/05 +0200, Sten wrote: > >why you do you declare a string in that way? > > > > char * f = "Hello"; > > > >'char* f' declares only a pointer to something. In this declaration > >"Hello" should be treated as constant char array by the compiler. Does > >the compiler complains about assigning const to non-const if you turn on > >-Wall??? > > Actually due to historical reasons it "Hello" doesn't get treated as a > constant char array type. I'd prefer it that way but... > > Some implementations though will treat "hello" as a constant string in > which case the pointer type and what it points to would be in conflict. I > don't think the standard allows that but I don't know and I certainly don't > know if any newer compilers do that. I do know that some pre- standard > compilers would put the string in a constant area and that would cause some > problems for programs that assumed they were modifiable. > > >Correct way to declare a pre-defined char array containing "Hello" would be: > > > > char f[] = "Hello"; > > > >That's a different! May the first line result in some confusions in the > >compiler?!? > > Not if it's standards compliant. That doesn't mean it's impossible but it > would be a pretty big point to mess up. Either form is 'correct' . Which > one you choose is a matter of choice, style and the specific > circumstance. Personally I would rarely use either one without a const > qualifier. > > 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/ >
2005-10-18 by Robert Adsett
At 09:08 PM 10/18/05 +0000, Guillermo Prandi wrote:
>Actually:
>
>char *f = "Hello";
>
>Left "Hello" in the ROM area. Whilst:
>
>char f[] = "Hello";
>
>Left "Hello" in the RAM area (after copying from ROM, of course).
>
>Guille
I rather suspect that's an allowed interpretation of the standard
then. GCC is quite good about that. It certainly follows the practice of
some UNIX compilers. Unfortunately that's a non-obvious type pun.
Thankfully lint (PC-Lint) catches it (although as a C++, not a C error,
Makes sense; AIUI the type of a string literal is different in the two
languages.)
char *f = "test";
e:\cygwin\home\radsett\newlib-lpc\test11.c 33 Info 1776: Converting a string
literal to char * is not const safe (initialization)
Thanks, another hole in my knowledge corrected.
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/2005-10-18 by Guillermo Prandi
I'm sure I've seen a flag somewhere in gcc to enable/disable the const-ization of string literals, but I can't find it right now. Guille --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote: > > At 09:08 PM 10/18/05 +0000, Guillermo Prandi wrote: > >Actually: > > > >char *f = "Hello"; > > > >Left "Hello" in the ROM area. Whilst: > > > >char f[] = "Hello"; > > > >Left "Hello" in the RAM area (after copying from ROM, of course). > > > >Guille > > I rather suspect that's an allowed interpretation of the standard > then. GCC is quite good about that. It certainly follows the practice of > some UNIX compilers. Unfortunately that's a non-obvious type pun. > > Thankfully lint (PC-Lint) catches it (although as a C++, not a C error, > Makes sense; AIUI the type of a string literal is different in the two > languages.) > > char *f = "test"; > e:\cygwin\home\radsett\newlib-lpc\test11.c 33 Info 1776: Converting a string > literal to char * is not const safe (initialization) > > Thanks, another hole in my knowledge corrected. > > 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/ >
2005-10-19 by Charles Manning
On Wednesday 19 October 2005 12:23, Guillermo Prandi wrote: > I'm sure I've seen a flag somewhere in gcc to enable/disable the > const-ization of string literals, but I can't find it right now. -fno-const-strings
2005-10-19 by bdmlpc
Hello Robert,
sorry for this last remark, but it is not an interpretation of C
standard.
char* f1 = "Hello";
In this case the compiler will allocate exact 4 bytes to store a
pointer to "Hello" in it. If you use 'f' (without an index) the
pointer will be loaded from its 4 byte position in memory. That's why
"Hello" is treated as constant initializer (by most compilers). It may
be tollerated by some compilers.
char f2[] = "Hello"; or
char f2[5+1] = "Hello";
In this case the compiler will allocate 6 bytes (5 + end delimieter
'\0') which are initialized with "Hello" in RAM. If you use 'f' the
pointer to this 6byte-array is used as an immediate value in assembler
because its position in RAM is fixed. See the following assignments.
Just try following assignments:
char buff1[] = "Hello";
char buff2[] = "World";
char* p1;
const char* p2 = "0123456";
p1 = buff1[]; //Is OK
p1[2] = 'L'; //Is OK
printf("%s", buff); //Will print "HeLlo"
p1++; //Is Ok
printf("%s", p1); //Will print "eLlo"
printf("%c", p2[3]); //Will print "3"
p2++; //Is ok, because only "0123456" is
//constant, not the pointer itself
buff1 = buff2; //Is not OK
buff1 = p1; //Is not OK
buff++; //Is not OK
Last tree lines will result in following errors:
error: incompatible types in assignment
error: incompatible types in assignment
error: wrong type argument to increment
because you try to change an "immediate" pointer. On the other hand
you would loose the reference to "Hello".
Due to C's complexity and the possibility to create code that nobody
else can understand than the programmer himself, there's a nice slogan
(I hope my translation is correct): "C is the language, where
programmers can create monuments of their brilliancy!" ;-)
Pointers and casts are my favourite and the best elements to protect
your code against others (if neccessary). This is called
job-protection! ;-)
Sten
--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
>
> At 09:08 PM 10/18/05 +0000, Guillermo Prandi wrote:
> >Actually:
> >
> >char *f = "Hello";
> >
> >Left "Hello" in the ROM area. Whilst:
> >
> >char f[] = "Hello";
> >
> >Left "Hello" in the RAM area (after copying from ROM, of course).
> >
> >Guille
>
> I rather suspect that's an allowed interpretation of the standard
> then. GCC is quite good about that. It certainly follows the
practice of
> some UNIX compilers. Unfortunately that's a non-obvious type pun.
>
> Thankfully lint (PC-Lint) catches it (although as a C++, not a C error,
> Makes sense; AIUI the type of a string literal is different in the two
> languages.)
>
> char *f = "test";
> e:\cygwin\home\radsett\newlib-lpc\test11.c 33 Info 1776:
Converting a string
> literal to char * is not const safe (initialization)
>
> Thanks, another hole in my knowledge corrected.
>
> 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/ >
2005-10-19 by Robert Adsett
At 02:47 PM 10/19/05 +0000, bdmlpc wrote: >sorry for this last remark, but it is not an interpretation of C >standard. What isn't? >char* f1 = "Hello"; Oh, I do realize the difference between a pointer and an array. After working with the language for a decade or two I should hope I do. The only vague area in my mind was the use of a string literal to initialize a non-constant pointer. A construct I don't think I've used on an ANSI/ISO compliant compiler. I do recall C and C++ regarding string literal as different types largely to allow the above statement to be legal C so that historical source will still compile and execute. The only question I had was whether the standard allowed the string literal to be const in that case (and it appears it does) in which case you get an implicit type punning where a non-const pointer points to a const area of memory. Not very type safe. I'd rather the construct was deprecated but I'm not going to hold my breath. Maybe C99 is moving in that direction? If so I've not heard that it is. 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/
2005-10-19 by Tom Walsh
bdmlpc wrote: >Due to C's complexity and the possibility to create code that nobody >else can understand than the programmer himself, there's a nice slogan >(I hope my translation is correct): "C is the language, where >programmers can create monuments of their brilliancy!" ;-) >Pointers and casts are my favourite and the best elements to protect >your code against others (if neccessary). This is called >job-protection! ;-) > > > Obviously it was Brian Kerningham that had said this about Dennis Ritche... TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-10-19 by rtstofer
--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote: > > bdmlpc wrote: > > >Due to C's complexity and the possibility to create code that nobody > >else can understand than the programmer himself, there's a nice slogan > >(I hope my translation is correct): "C is the language, where > >programmers can create monuments of their brilliancy!" ;-) > >Pointers and casts are my favourite and the best elements to protect > >your code against others (if neccessary). This is called > >job-protection! ;-) > > > > > > > Obviously it was Brian Kerningham that had said this about Dennis Ritche... > > TomW And Niklaus Wirth had a different idea with Pascal. Richard
2005-10-19 by more_effective
Another slogan that makes me laugh a lot says: "C is a write-only language" :)) wolfish --- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote: > > --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote: > > > > bdmlpc wrote: > > > > >Due to C's complexity and the possibility to create code that > nobody > > >else can understand than the programmer himself, there's a nice > slogan > > >(I hope my translation is correct): "C is the language, where > > >programmers can create monuments of their brilliancy!" ;-) > > >Pointers and casts are my favourite and the best elements to > protect > > >your code against others (if neccessary). This is called > > >job-protection! ;-) > > > > > > > > > > > Obviously it was Brian Kerningham that had said this about Dennis
> Ritche... > > > > TomW > > And Niklaus Wirth had a different idea with Pascal. > > Richard >
2005-10-20 by Robert Adsett
At 07:30 PM 10/19/05 +0000, more_effective wrote: >Another slogan that makes me laugh a lot says: "C is a write-only >language" >:)) Obviously coined by someone who'd never worked with APL :) 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/