Re: Unomitted frame pointers

Re: Unomitted frame pointers

[Thomas R. Truscott]

Off-topic, but the hello.c program does:

	write(2, "Hello World!\n\0", 16);

The string length is 15, not 16.
It would be nice if gcc issued warnings for compile-time constant
string/length pairs where the length is too large.

I do that in my local copy of gcc, and it routinely finds
coding mistakes for memcpy().
Perhaps this could somehow be an "attribute" that gcc can check.

(Hmm, the attribute thing is too limited, what would be really
nice is a way to write code that does general compile-time argument
checking.  Then one could do more thorough checks such as is
done for printf/scanf.  And the same code could be invoked
at run time ... oops, way off topic.)

Tom Truscott

Re: Unomitted frame pointers

[jlh]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]


> Off-topic, but the hello.c program does:
> 	write(2, "Hello World!\n\0", 16);
> The string length is 15, not 16.

15 is what gets allocated for storing the string (counting
the additional \0 that always gets appened to string constants).
But neither the explicit nor the implicit \0 should be printed
to the console, so the call should definitely read:

     write(2, "Hello World!\n", 13);

jlh

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

RE: Unomitted frame pointers

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of jlh
> Sent: 10 December 2004 16:05
> To: Thomas R. Truscott

> > Off-topic, but the hello.c program does:
> > 	write(2, "Hello World!\n\0", 16);
> > The string length is 15, not 16.
> 
> 15 is what gets allocated for storing the string (counting
> the additional \0 that always gets appened to string constants).
> But neither the explicit nor the implicit \0 should be printed
> to the console, so the call should definitely read:
> 
>      write(2, "Hello World!\n", 13);
> 
> jlh


  Except of course on targets where '\n' expands to a two char CR-LF
combination.

  So really the safe way to code this is

#define HELLOSTRING "Hello World!\n"

      write (2, HELLOSTRING, strlen(HELLOSTRING)-1);

and let the compiler statically compute the string length for you at
compiletime.  The #define is used to make sure we don't end up with two copies
of the string that get out of sync, as would be bound to happen sooner or later
if we wrote

      write (2, "Hello World!\n", strlen("Hello World!\n")-1); 

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Unomitted frame pointers

[Nathan Sidwell]

Dave Korn wrote:
>>-----Original Message-----
>>From: gcc-owner On Behalf Of jlh

>>     write(2, "Hello World!\n", 13);

> 
>   Except of course on targets where '\n' expands to a two char CR-LF
> combination.

you're smoking something :)

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: Unomitted frame pointers

[Andreas Schwab]

"Dave Korn" <dave.korn@artimi.com> writes:

>   So really the safe way to code this is
>
> #define HELLOSTRING "Hello World!\n"
>
>       write (2, HELLOSTRING, strlen(HELLOSTRING)-1);

No, it's

        write (2, HELLOSTRING, strlen(HELLOSTRING));

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: Unomitted frame pointers

[Dave Korn]

> -----Original Message-----
> From: Andreas Schwab [mailto:schwab@suse.de] 
> Sent: 10 December 2004 16:33

> "Dave Korn" writes:
> 
> >   So really the safe way to code this is
> >
> > #define HELLOSTRING "Hello World!\n"
> >
> >       write (2, HELLOSTRING, strlen(HELLOSTRING)-1);
> 
> No, it's
> 
>         write (2, HELLOSTRING, strlen(HELLOSTRING));
> 
> Andreas.
> 


  Duh.  Yes, of course I needn't allow for the NUL-terminator......


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

RE: Unomitted frame pointers

[Dave Korn]

> -----Original Message-----
> From: Nathan Sidwell 
> Sent: 10 December 2004 16:30

> Dave Korn wrote:
> >>-----Original Message-----
> >>From: gcc-owner On Behalf Of jlh
> 
> >>     write(2, "Hello World!\n", 13);
> 
> > 
> >   Except of course on targets where '\n' expands to a two char CR-LF
> > combination.
> 
> you're smoking something :)
> 


  Not at all.  That's why sizeof(char) sometimes returns 1, and sometimes
returns 2, depending on the char!

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Unomitted frame pointers

[Thomas R. Truscott]

>         write (2, HELLOSTRING, strlen(HELLOSTRING));

People sometimes mismatch the string names, e.g.:

          write (2, HELLOSTRING, strlen(JELLOSTRING));
                                        ^

To reduce that hazard we have a macro:

#define TEXTARG(s)    s, (int)strlen(s)

          write (2, TEXTARG (HELLOSTRING));

But it looks odd, and people don't use it as much as they could.

Tom Truscott

P.S.  here is another thing gcc misses:

          memcpy("hi", p, 2);  /* "cannot modify string literal" */

Re: Unomitted frame pointers

[Paul Brook]

On Friday 10 December 2004 16:54, Thomas R. Truscott wrote:
> P.S.  here is another thing gcc misses:
>
>           memcpy("hi", p, 2);  /* "cannot modify string literal" */

Works for me:

paul@wren:~$ gcc -Wwrite-strings test.c
test.c: In function 'main':
test.c:9: warning: passing argument 1 of 'memcpy' discards qualifiers from 
pointer target type

Paul

Re: Unomitted frame pointers

[Nathan Sidwell]

Dave Korn wrote:
>>-----Original Message-----
>>From: Nathan Sidwell 
>>Sent: 10 December 2004 16:30
> 
> 
>>Dave Korn wrote:
>>
>>>>-----Original Message-----
>>>>From: gcc-owner On Behalf Of jlh
>>
>>>>    write(2, "Hello World!\n", 13);
>>
>>>  Except of course on targets where '\n' expands to a two char CR-LF
>>>combination.
>>
>>you're smoking something :)
>>
>   Not at all.  That's why sizeof(char) sometimes returns 1, and sometimes
> returns 2, depending on the char!

I stand by my earlier assertion :)

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

[OT] RE: Unomitted frame pointers

[Dave Korn]

> -----Original Message-----
> From: Nathan Sidwell 
> Sent: 10 December 2004 17:54
> To: Dave Korn
> Cc: 'jlh'; 'Thomas R. Truscott'; gcc
> Subject: Re: Unomitted frame pointers
> 
> Dave Korn wrote:
> >>-----Original Message-----
> >>From: Nathan Sidwell 
> >>Sent: 10 December 2004 16:30

[Cc line trimmed owing to OT-ness]

> > 
> >>Dave Korn wrote:
> >>
> >>>>-----Original Message-----
> >>>>From: gcc-owner On Behalf Of jlh
> >>
> >>>>    write(2, "Hello World!\n", 13);
> >>
> >>>  Except of course on targets where '\n' expands to a two 
> char CR-LF
> >>>combination.
> >>
> >>you're smoking something :)
> >>
> >   Not at all.  That's why sizeof(char) sometimes returns 1, 
> and sometimes
> > returns 2, depending on the char!
> 
> I stand by my earlier assertion :)
> 

  I presume now would not be a good time to explain my theories about how it
also varies with latitude, longitude, and phase of the moon ?


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Unomitted frame pointers

[Kai Henningsen]

paul@codesourcery.com (Paul Brook)  wrote on 10.12.04 in <200412101726.33264.paul@codesourcery.com>:

> On Friday 10 December 2004 16:54, Thomas R. Truscott wrote:
> > P.S.  here is another thing gcc misses:
> >
> >           memcpy("hi", p, 2);  /* "cannot modify string literal" */
>
> Works for me:
>
> paul@wren:~$ gcc -Wwrite-strings test.c
> test.c: In function 'main':
> test.c:9: warning: passing argument 1 of 'memcpy' discards qualifiers from
> pointer target type

Would it be hard to say what qualifier(s) here? I'm sure that would make  
many programmers go "duh!" significantly faster in those moments.

MfG Kai