Re: [9fans] plan or side effect

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

[Thomas Bushnell, BSG]

dhog@plan9.bell-labs.com (David Gordon Hogan) writes:

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

Actually, that's glibc that's doing the trick, not gcc.

As I said, since GCC and glibc are maintained separately, gcc is very
careful to stay away from magic related to things like "strcpy".
(There is an exception for "main"; some magic happens there, and GCC
and glibc worked out carefully how it should happen.)

If you look at <bits/string2.h> you can see the glibc magic for
strcpy.  It boils down to the following:

  define strcpy(dest, src) \
  (__extension__ (__builtin_constant_p (src)				      \
		  ? (__string2_1bptr_p (src) && strlen (src) + 1 <= 8	      \
		     ? __strcpy_small (dest, __strcpy_args (src),	      \
				       strlen (src) + 1)		      \
		     : (char *) memcpy (dest, src, strlen (src) + 1))	      \
		  : strcpy (dest, src)))

The only compiler support for this is the __builtin_constant_p
function, which is a GCC builtin.  (There is a GCC __builtin_memcpy,
as well, which does get used for larger strings inside the guts of
memcpy, and expands to an inline block memory copy instruction.)

The function __strcpy_small (which is invoked in the case where src is
the constant "xyzzy") is an inline function that moves the bytes one
word at a time, and then the compiler simply optimizes those
assignments in the usual way to produce:

foo:
	pushl %ebp
	movl %esp,%ebp
	movl s,%eax
	movl $2054846840,(%eax)
	movw $121,4(%eax)
	leave
	ret

Re: [9fans] plan or side effect

[Boyd Roberts]

"Thomas Bushnell, BSG" wrote:
> If you look at <bits/string2.h> you can see the glibc magic for
> strcpy.  It boils down to the following:
> 
>   define strcpy(dest, src) \
>   (__extension__ (__builtin_constant_p (src)                                  \
>                   ? (__string2_1bptr_p (src) && strlen (src) + 1 <= 8         \
>                      ? __strcpy_small (dest, __strcpy_args (src),             \
>                                        strlen (src) + 1)                      \
>                      : (char *) memcpy (dest, src, strlen (src) + 1))         \
>                   : strcpy (dest, src)))
> 

s/magic/stupidity/

Re: [9fans] plan or side effect

[Thomas Bushnell, BSG]

boyd@strakt.com (Boyd Roberts) writes:

> s/magic/stupidity/

The amazing thing is that you think performance is hugely important,
so much so, that you claim run time of compilation is the most
important thing.  Then when another system does something faster, you
call it "stupid".  Puhleez.  If your real opinion is just "Whatever
Plan 9 does is brilliant, and anything different is stupid", then say
it, instead of pretending to have reasoned opinions.

For my part, Plan 9 does some things very well, and other things less
well.  I enjoy learning from the successes of Plan 9, but it's a real
shame that many people here have a kind of allergic reaction to
learning from the successes of anything else.

Thomas

Re: [9fans] plan or side effect

[Sean Quinlan]

You are confusing

	We kept it simple and as a result it goes fast

with

	We made it massively more complex to squeeze out a little more performance.


"Thomas Bushnell, BSG" wrote:
> 
> boyd@strakt.com (Boyd Roberts) writes:
> 
> > s/magic/stupidity/
> 
> The amazing thing is that you think performance is hugely important,
> so much so, that you claim run time of compilation is the most
> important thing.  Then when another system does something faster, you
> call it "stupid".  Puhleez.  If your real opinion is just "Whatever
> Plan 9 does is brilliant, and anything different is stupid", then say
> it, instead of pretending to have reasoned opinions.
> 
> For my part, Plan 9 does some things very well, and other things less
> well.  I enjoy learning from the successes of Plan 9, but it's a real
> shame that many people here have a kind of allergic reaction to
> learning from the successes of anything else.
> 
> Thomas

Re: [9fans] plan or side effect

[ozan s yigit]

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

>					      ... but it's a real
> shame that many people here have a kind of allergic reaction to
> learning from the successes of anything else.

so far as we can tell, the only thing you wish we would learn has to do
with license paperwork. i've been using it since b2 release in 87, so
i'm curious what else you have in mind.

oz

Re: [9fans] plan or side effect

[Thomas Bushnell, BSG]

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

> so far as we can tell, the only thing you wish we would learn has to do
> with license paperwork. i've been using it since b2 release in 87, so
> i'm curious what else you have in mind.

The referenced thread was about more efficient ways of implementing
strcpy than the trivial one.  I'm sure there are more than that one.

Thomas

Re: [9fans] plan or side effect

[Boyd Roberts]

"Thomas Bushnell, BSG" wrote:
> The referenced thread was about more efficient ways of implementing
> strcpy than the trivial one.  I'm sure there are more than that one.

If you had a PDP-11 or slower ...

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.

Re: [9fans] plan or side effect

[Dan Cross]

No Tom, the point is that it's easier to verify that something is
correct if it's simpler.  Performance is, to a lot of folks (myself
included) less important than correctness.

These are all pretty straight forward engineering tradeoffs; how much
time am I willing to invest in making something go faster?  Is it worth
while for me to do so?  What is the cost of maintaining that thing?  If
you're a resource constrained group like 1127, and performance isn't
such a big deal to you, you're not going to worry about making a
super-fast whiz bang optimizer, or about hand coding the universe's
most efficient implementation of strcpy.  It's just not important.

Another good engineering principle is ``optimize for the most common
case.'' Imagine that you build a system, and you find that you spend
90% of your time in one, rather small, part of that system.  If the
performance of the system is still acceptable, you probably aren't
going to worry about it.  But, if you do need to make it faster, where
do you get the biggest return on your investment in optimizing: in that
one part, or on the system overall?  Usually, it's in that one part.

The Plan 9 guys at the labs took these things to heart when they built
the compiler suite.  They saw themselves spending a lot of time
compiling, and not worrying too much about performance of the compiled
code.  The end result is what we see in 8[acl] et al; you get very
speedy compilation, and medium quality output with acceptable
performance.  You don't have the maintenance overhead of something
really big like gcc.  Overall, the system is very well balanced in
terms of compiler output quality, compiler speed, and maintenance costs
associated with the compiler suite.  The compiler is well suited to the
unique Plan 9 environment.  Really, I don't see what your problem with
the Plan 9 compilers are, Tom.

	- Dan C.

Re: [9fans] plan or side effect

[Ralph Corderoy]

Hi,

Dan Cross <9fans@cse.psu.edu> wrote:
> No Tom, the point is that it's easier to verify that something is
> ...
> the Plan 9 compilers are, Tom.

Even I didn't bother to read this seeing it started and ended with a
deliberate wind-up that *Thomas* has publically asked you to stop
doing.  Please keep c.o.plan9/9fans civil.  Even if you vehemently
disagree.

Cheers,


Ralph.

Re: [9fans] plan or side effect

[Thomas Bushnell, BSG]

cross@math.psu.edu (Dan Cross) writes:

> ...Tom...

If you make correctness such an ideal that you are willing to
sacrifice the speed of a correct program to make it "more likely to be
correct", then why do you insist on getting my name wrong?

Are you really *that* stupid?

Thomas

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;

Re: [9fans] plan or side effect

[Boyd Roberts]

David Gordon Hogan wrote:
> 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?

I'm with dhog [I can already smell the napalm burning ...]

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: 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..