Re: macro fun [Re: [9fans] plan or side effect]

Re: macro fun [Re: [9fans] plan or side effect]

[forsyth]

sorry, i'd sent that note before yours arrived.
that's fine.   i can't tell from the gcc manual page
on FreeBSD but presumably -ansi switches off
gcc extensions of one sort or another but doesn't
check conformance.

Re: macro fun [Re: [9fans] plan or side effect]

[Douglas A. Gwyn]

forsyth@caldo.demon.co.uk wrote:
> ... presumably -ansi switches off gcc extensions of one sort
> or another but doesn't check conformance.

Checking a program for strict conformance appears to be one
of those finitely uncomputable tasks.  The best one can hope
for is that readily detectable violations are flagged.  The
C standard requires diagnostics for most of those..

Re: macro fun [Re: [9fans] plan or side effect]

[forsyth]

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

yes, i did mean to restrict it to reasonable static analysis.
actually one can hope for more than `readily detectable
violations'--global static analysers can do a lot, even for C.


[-- Attachment #2: Type: message/rfc822, Size: 2061 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: macro fun [Re: [9fans] plan or side effect]
Date: Tue, 19 Mar 2002 09:50:03 GMT
Message-ID: <3C96C3BA.CFB711B0@null.net>

forsyth@caldo.demon.co.uk wrote:
> ... presumably -ansi switches off gcc extensions of one sort
> or another but doesn't check conformance.

Checking a program for strict conformance appears to be one
of those finitely uncomputable tasks.  The best one can hope
for is that readily detectable violations are flagged.  The
C standard requires diagnostics for most of those..

Re: macro fun [Re: [9fans] plan or side effect]

[forsyth]

>> according to gcc, [t.c] is strictly conforming. it compiles
> perfectly.

>That's not at all the same thing.

since he said -ansi -pendantic (or some such) i suspect he
expected it to complain, and it probably should.

Re: macro fun [Re: [9fans] plan or side effect]

[Thomas Bushnell, BSG]

forsyth@caldo.demon.co.uk writes:

> >> according to gcc, [t.c] is strictly conforming. it compiles
> > perfectly.
> 
> >That's not at all the same thing.
> 
> since he said -ansi -pendantic (or some such) i suspect he
> expected it to complain, and it probably should.

No, -pedantic says "issue all the warnings and errors that ANSI
mandates, even when they are stupid warnings or errors".  It does not
say "warn for all non-ANSI constructions".  

Re: [9fans] plan or side effect

[David Gordon Hogan]

> No, in general GCC does not have such knowledge.  
> 
> If it is able to inline the function, then of course it can do the
> optimization, but an inlined function isn't a function call at all, so
> that's really a different case.
> 
> Also, GCC has some builtin functions; it knows the behavior of those.
> But not (in general) library functions.

It certainly knows about strcpy() and memmove() (or
whatever they're #defined to in the headers).  So for
instance,

	strcpy(s, "xyzzy");

will get replaced with a bunch of instructions to store the
appropriate constant values in s.

I'm just reporting, I don't think it's a particularly good thing.
Like, do we really need that extra .1% speed improvement,
at the expense of code size, compile speed, and transparent
behaviour?

When I say .1%, I'm just pulling a number out of the air.
Clearly, if your program is composed entirely out of
strcpy's of constants, the improvement could be much
larger(!).  But, I claim that this is a pathological case,
and the time wasted on such `improvements' is generally
better spent elsewhere (like, maybe, some day, someone
will simplify the morass of #ifdefs that GCC and Binutils
are afflicted with...).

Re: [9fans] plan or side effect

[Boyd Roberts]

"Thomas Bushnell, BSG" wrote:
> 
> boyd@strakt.com (Boyd Roberts) writes:
> 
> > s/magic/stupidity/
> 
> The amazing thing is that you think performance is hugely important, ...

s/amazing //
s/performance/correctness/

Re: [9fans] plan or side effect

[Thomas Bushnell, BSG]

boyd@strakt.com (Boyd Roberts) writes:

> "Thomas Bushnell, BSG" wrote:
> > 
> > boyd@strakt.com (Boyd Roberts) writes:
> > 
> > > s/magic/stupidity/
> > 
> > The amazing thing is that you think performance is hugely important, ...
> 
> s/amazing //
> s/performance/correctness/

Um, so, is there a bug in the glibc implementation of strcpy?

I mean, correctness is a binary property--you've got it, or you don't.

macro fun [Re: [9fans] plan or side effect]

[ozan s. yigit]

Thomas Bushnel [in response to boyd]
> > 
> > s/amazing //
> > s/performance/correctness/
> 
> Um, so, is there a bug in the glibc implementation of strcpy?

Um, so, would you consider the following a bug in gcc, glibc or both:

bent!oz| cc -o t t.c
bent!oz| ./t
hello world!
bent!oz| cc -O -o t t.c
t.c:3: parse error before `__extension__'

i'll let you figure out what t.c trivially contains to make a soup
with the "optimized" macro, thanks to simple textual substitution. :)

so would be be fair to say the generated output is not correct, and boyd
is right to be concerned?

oz
---
gag reflex is an essential part of computing.

Re: macro fun [Re: [9fans] plan or side effect]

[Thomas Bushnell, BSG]

"ozan s. yigit" <oz@cs.yorku.ca> writes:

> bent!oz| cc -o t t.c
> bent!oz| ./t
> hello world!
> bent!oz| cc -O -o t t.c
> t.c:3: parse error before `__extension__'
> 
> i'll let you figure out what t.c trivially contains to make a soup
> with the "optimized" macro, thanks to simple textual substitution. :)

I have no clue.  Probably you included the wrong header file, or none,
or in some other way violated the actual rules of the language.

Re: macro fun [Re: [9fans] plan or side effect]

[Douglas A. Gwyn]

"ozan s. yigit" wrote:
> i'll let you figure out what t.c trivially contains to make a soup
> with the "optimized" macro, thanks to simple textual substitution.

Is t.c a strictly conforming program?  If not, you got what you asked
for.

Re: macro fun [Re: [9fans] plan or side effect]

[ozan s. yigit]

Douglas A. Gwyn writes:

> > i'll let you figure out what t.c trivially contains to make a soup
> > with the "optimized" macro, thanks to simple textual substitution.
> 
> Is t.c a strictly conforming program?  If not, you got what you asked
> for.

according to gcc, it is strictly conforming. it compiles
perfectly. here is more strict version:

	bent!oz| gcc -Wall -ansi -pedantic -o t t.c
	bent!oz| ./t
	hello boyd!

now, with -O

	bent!oz| gcc -O -Wall -ansi -pedantic -o t t.c
	t.c:4: parse error before `__extension__'

this is absolute crap. here is t.c. so obvious, i'm surprised
you of all people had to comment.

	#include <stdio.h>
	#include <string.h>
	
	extern char *strcpy(char *, const char *);

	int main(int argc, char **argv) {
        	char buf[10];
	        strcpy(buf, "hello boyd!");
	        printf("%s\n", buf);
        	return 0;
	}


oz
---
complexity is its own petard. -- anon
oz@cs.yorku.ca || www.cs.yorku.ca/~oz

Re: macro fun [Re: [9fans] plan or side effect]

[Mike Haertel]

>this is absolute crap. here is t.c. so obvious, i'm surprised
>you of all people had to comment.
>
>	#include <stdio.h>
>	#include <string.h>
>	
>	extern char *strcpy(char *, const char *);
>
>	int main(int argc, char **argv) {
>        	char buf[10];
>	        strcpy(buf, "hello boyd!");
>	        printf("%s\n", buf);
>        	return 0;
>	}

This is not strictly conforming.

 From the C89 standard, section 4.1.6, "Use of Library Functions":

"Any function declared in a header may additionally be implemented
as a macro defined in the header, so a library function should not
be declared explicitly if its header is included."

Re: macro fun [Re: [9fans] plan or side effect]

[ozan s yigit]

mike@ducky.net (Mike Haertel) writes:

> This is not strictly conforming.

sigh. the first example had a re-implementation, but that too is
deemed illegal without "undef strcpy" just in case.

oz
---
furthermore, I am of the opinion that cpp must be destroyed.
                      - Cato the Elder (Marcus Porcius Cato)

Re: macro fun [Re: [9fans] plan or side effect]

[Mike Haertel]

>	#include <stdio.h>
>	#include <string.h>
>	
>	extern char *strcpy(char *, const char *);
>
>	int main(int argc, char **argv) {
>        	char buf[10];
>	        strcpy(buf, "hello boyd!");
>	        printf("%s\n", buf);
>        	return 0;
>	}

Another way your program is not strictly conforming
is that the buffer is too small for the string you
are copying into it.

So you are asking to lose in more ways than one.

Re: macro fun [Re: [9fans] plan or side effect]

[Thomas Bushnell, BSG]

"ozan s. yigit" <oz@cs.yorku.ca> writes:

> this is absolute crap. here is t.c. so obvious, i'm surprised
> you of all people had to comment.
> 
> 	#include <stdio.h>
> 	#include <string.h>
> 	
> 	extern char *strcpy(char *, const char *);
> 
> 	int main(int argc, char **argv) {
>         	char buf[10];
> 	        strcpy(buf, "hello boyd!");
> 	        printf("%s\n", buf);
>         	return 0;
> 	}

This is not standard conformant.

"If a program declares or defines an identifier with the same name as
an identifier reserved in that context...the behavior is undefined."
(ANSI C, 4.1.2.1)

The "strcpy" identifier is reserved in external contexts by section
4.11.2.3.

Posix guarantees you that "redeclarations" like yours are safe, but
that's only for the identifiers Posix specifies.  ANSI C's identifiers
come with so such guarantee, intentionally.

GCC does not attempt to catch such errors, nor is it required to.

Thomas

Re: macro fun [Re: [9fans] plan or side effect]

[Thomas Bushnell, BSG]

"ozan s. yigit" <oz@cs.yorku.ca> writes:

> according to gcc, it is strictly conforming. 

GCC does not assert that anything is strictly conforming.  You used
"-Wall -ansi -pedantic", but the documentation for GCC says:

 Some users try to use `-pedantic' to check programs for strict ANSI C
 conformance.  They soon find that it does not do quite what they
 want: it finds some non-ANSI practices, but not all--only those for
 which ANSI C *requires* a diagnostic.

 A feature to report any failur to conform to ANSI C might be useful
 in some instances, but would require considerable additional work and
 would be quite different from `-pedantic'.

Thomas

Re: macro fun [Re: [9fans] plan or side effect]

[ozan s yigit]

"Thomas Bushnell, BSG" <tb+usenet@becket.net> writes:

>  Some users try to use `-pedantic' to check programs for strict ANSI C
>  conformance.  They soon find that it does not do quite what they
>  want: it finds some non-ANSI practices, but not all--only those for
>  which ANSI C *requires* a diagnostic.

thanks. old habits die hard. i'll read the current documentation and
the standard carefully before my next abuse of the compiler, which will
be a monthly event. :)

>  A feature to report any failur to conform to ANSI C might be useful
>  in some instances, but would require considerable additional work and
>  would be quite different from `-pedantic'.

indeed, and i don't know if gcc should necessarily try to do this sort
of analysis. unfortunately no lint i have access to (including the quite
superior sun lint) would complain. lclint sort of does, but it doesn't
get it right:

boyd.c:3:14: Name strcpy is reserved for future ANSI library extensions. 
    Functions that begin with "str" and a lowercase letter may be added to
    <stdlib.h> or <string.h>. (See ANSI, Section 4.13.7)
  External name is reserved for system in ANSI standard. (-ansireserved will
  suppress message)

i did not try any harder.

oz
-- 
The more I live with #ifdef, the less I like it. -- henry spencer

Re: macro fun [Re: [9fans] plan or side effect]

[Ralph Corderoy]

Hi ozan,

> > > i'll let you figure out what t.c trivially contains to make a soup
> > > with the "optimized" macro, thanks to simple textual substitution.
> > 
> > Is t.c a strictly conforming program?  If not, you got what you asked
> > for.
> 
> according to gcc, it is strictly conforming. it compiles
> perfectly. here is more strict version:
> 
>       bent!oz| gcc -Wall -ansi -pedantic -o t t.c
>       bent!oz| ./t
>       hello boyd!
> 
> now, with -O
> 
>       bent!oz| gcc -O -Wall -ansi -pedantic -o t t.c
>       t.c:4: parse error before `__extension__'
> 
> this is absolute crap. here is t.c.

In this case, it is t.c that's crap.

>       #include <stdio.h>
>       #include <string.h>
>       
>       extern char *strcpy(char *, const char *);

You can't do that in ANSI C and expect not to get bitten.  The compiler
is allowed to implement a standard library function as a macro if they
wish, but must still implement it as a function so its address can be
taken.

If you wish to refer to the function, without knowing if a macro
exists, you are meant to do either

    #ifdef strcpy
    #undef strcpy
    #endif

or

    extern char *(strcpy)(char *, const char *);

See a book like Harbison and Steele's _C, A Reference Manual_ for more
info on writing compliant source.

IBM's AIX C compiler also #defines strcpy as an optimisation.

    $ cc -qlanglvl=ansi -E t.c | grep strcpy
            extern char     *strcpy(char *, const char *);
    extern char *__strcpy(char *,const char *);
            __strcpy(buf,"hello boyd!");

So that doesn't give the effect you intended either.

Cheers,


Ralph.

Re: macro fun [Re: [9fans] plan or side effect]

[Douglas A. Gwyn]

Ralph Corderoy wrote:
>     #ifdef strcpy
>     #undef strcpy
>     #endif

Just plain #undef strcpy will suffice.

Re: macro fun [Re: [9fans] plan or side effect]

[Ralph Corderoy]

Hi Doug,

> >     #ifdef strcpy
> >     #undef strcpy
> >     #endif
> 
> Just plain #undef strcpy will suffice.

You're quite right.  Funny how Harbison and Steele give those three
lines yet also say an #undef for an undefined symbol is fine.


Ralph.

Re: macro fun [Re: [9fans] plan or side effect]

[AMSRL-CI-CN]

"ozan s. yigit" <oz@cs.yorku.ca> wrote in message
news:4da3d9af.0203150929.1d3154d2@posting.google.com...
>> according to gcc, [t.c] is strictly conforming. it compiles
> perfectly.

That's not at all the same thing.

> #include <stdio.h>
> #include <string.h>
> extern char *strcpy(char *, const char *);

The C standard is very explicit about not doing this;
see subclauses 7.1.3 and 7.1.4.
What you have is not a strictly conforming program,
so its lack of success with a particular C implementation
does not indicate that the C implementation is not conforming.

It might be surprising that programmers need to be more careful,
but there are many aspects of C like that.

Re: macro fun [Re: [9fans] plan or side effect]

[Boyd Roberts]

"ozan s. yigit" wrote:
>         int main(int argc, char **argv) {
>                 char buf[10];
>                 strcpy(buf, "hello boyd!");
>                 printf("%s\n", buf);

I was pretty sure what it was; meta macro woe to inline some 'orrible glop.

I think I'd re-declare:

    char buf[12];

'cos strlen("hello boyd!") == 11

Re: macro fun [Re: [9fans] plan or side effect]

[ozan s. yigit]

one last hello boyd program. i'm curious if this one
is considered non-conforming too.

#include <stdio.h>
#include <string.h>

int main(int argc, char **argv) {
        char buf[256];
        strcpy(buf,
	  strcpy(buf,
            strcpy(buf,
              strcpy(buf,
                strcpy(buf,
                  strcpy(buf,
                    strcpy(buf,
                      strcpy(buf, "hello boyd!"))))))));
        printf("%s\n", buf);
        return 0;
}

bent!oz| gcc -O2 -o t t.c
cpp0: Cannot allocate 939136576 bytes after allocating 457620 bytes

i'll go buy more memory.

oz
---
entia non sunt multiplicanda praeter necessitatem -- william of occam

Re: macro fun [Re: [9fans] plan or side effect]

[Wladimir Mutel]

В статье <4da3d9af.0203151259.13de5c01@posting.google.com> ozan s. yigit написал(а):
> one last hello boyd program. i'm curious if this one
> is considered non-conforming too.

> bent!oz| gcc -O2 -o t t.c
> cpp0: Cannot allocate 939136576 bytes after allocating 457620 bytes
> 
> i'll go buy more memory.

	What version of gcc ? gcc-3.0.4 eats this well.

Re: macro fun [Re: [9fans] plan or side effect]

[ozan s. yigit]

on nested hello boyd:

> 	What version of gcc ? gcc-3.0.4 eats this well.

2.95.3 (SuSE), 2.96 (RH 7.1) and gcc-3.0.4 all fail with the glibc
that is present in those installations (1.2 i think).

oz
---
it is very difficult to sing and throw up at the same time. - grace slick

Re: macro fun [Re: [9fans] plan or side effect]

[Douglas A. Gwyn]

"ozan s. yigit" wrote:
> i'm curious if this one
> is considered non-conforming too.

Yes, because the source and destination strings overlap.

Re: macro fun [Re: [9fans] plan or side effect]

[ozan s yigit]

"Douglas A. Gwyn" <DAGwyn@null.net> writes:

> "ozan s. yigit" wrote:
> > i'm curious if this one
> > is considered non-conforming too.
> 
> Yes, because the source and destination strings overlap.

but that is not the problem.
a non-overlapping version blows up a combination of gcc/cpp
and glibc the same way.

oz
---
#include <stdio.h>
#include <string.h>

int
main(int argc, char **argv)
{
    char b1[15];
    char b2[15];
    char b3[15];
    char b4[15];
    char b5[15];
    strcpy(b5,
        strcpy(b4,
            strcpy(b3,
                strcpy(b2,
                    strcpy(b1, "hello boyd!")))));
    printf("%s\n", b5);
    return 0;