9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: macro fun [Re: [9fans] plan or side effect]
@ 2002-03-19 10:57 forsyth
  0 siblings, 0 replies; 25+ messages in thread
From: forsyth @ 2002-03-19 10:57 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-18 10:33           ` Thomas Bushnell, BSG
@ 2002-03-21 11:01             ` ozan s yigit
  0 siblings, 0 replies; 25+ messages in thread
From: ozan s yigit @ 2002-03-21 11:01 UTC (permalink / raw)
  To: 9fans

"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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-19  9:49             ` Douglas A. Gwyn
@ 2002-03-21 11:01               ` Ralph Corderoy
  0 siblings, 0 replies; 25+ messages in thread
From: Ralph Corderoy @ 2002-03-21 11:01 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-15 17:48         ` ozan s. yigit
                             ` (5 preceding siblings ...)
  2002-03-18 10:38           ` AMSRL-CI-CN
@ 2002-03-20 13:38           ` Boyd Roberts
  6 siblings, 0 replies; 25+ messages in thread
From: Boyd Roberts @ 2002-03-20 13:38 UTC (permalink / raw)
  To: 9fans

"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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-19  9:49           ` Douglas A. Gwyn
@ 2002-03-19 16:01             ` ozan s yigit
  0 siblings, 0 replies; 25+ messages in thread
From: ozan s yigit @ 2002-03-19 16:01 UTC (permalink / raw)
  To: 9fans

"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;


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-18 18:05 forsyth
@ 2002-03-19  9:50 ` Douglas A. Gwyn
  0 siblings, 0 replies; 25+ messages in thread
From: Douglas A. Gwyn @ 2002-03-19  9:50 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-18 10:38         ` ozan s. yigit
  2002-03-18 13:08           ` Wladimir Mutel
@ 2002-03-19  9:49           ` Douglas A. Gwyn
  2002-03-19 16:01             ` ozan s yigit
  1 sibling, 1 reply; 25+ messages in thread
From: Douglas A. Gwyn @ 2002-03-19  9:49 UTC (permalink / raw)
  To: 9fans

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

Yes, because the source and destination strings overlap.


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-18 10:33           ` Ralph Corderoy
@ 2002-03-19  9:49             ` Douglas A. Gwyn
  2002-03-21 11:01               ` Ralph Corderoy
  0 siblings, 1 reply; 25+ messages in thread
From: Douglas A. Gwyn @ 2002-03-19  9:49 UTC (permalink / raw)
  To: 9fans

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

Just plain #undef strcpy will suffice.


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-18 13:08           ` Wladimir Mutel
@ 2002-03-19  9:49             ` ozan s. yigit
  0 siblings, 0 replies; 25+ messages in thread
From: ozan s. yigit @ 2002-03-19  9:49 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
@ 2002-03-18 18:05 forsyth
  2002-03-19  9:50 ` Douglas A. Gwyn
  0 siblings, 1 reply; 25+ messages in thread
From: forsyth @ 2002-03-18 18:05 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-18 11:22 forsyth
@ 2002-03-18 17:37 ` Thomas Bushnell, BSG
  0 siblings, 0 replies; 25+ messages in thread
From: Thomas Bushnell, BSG @ 2002-03-18 17:37 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-18 10:38         ` ozan s. yigit
@ 2002-03-18 13:08           ` Wladimir Mutel
  2002-03-19  9:49             ` ozan s. yigit
  2002-03-19  9:49           ` Douglas A. Gwyn
  1 sibling, 1 reply; 25+ messages in thread
From: Wladimir Mutel @ 2002-03-18 13:08 UTC (permalink / raw)
  To: 9fans

В статье <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.


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
@ 2002-03-18 11:22 forsyth
  2002-03-18 17:37 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 25+ messages in thread
From: forsyth @ 2002-03-18 11:22 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-15 17:48         ` ozan s. yigit
                             ` (4 preceding siblings ...)
  2002-03-18 10:33           ` Ralph Corderoy
@ 2002-03-18 10:38           ` AMSRL-CI-CN
  2002-03-20 13:38           ` Boyd Roberts
  6 siblings, 0 replies; 25+ messages in thread
From: AMSRL-CI-CN @ 2002-03-18 10:38 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-15 10:18       ` Douglas A. Gwyn
  2002-03-15 17:48         ` ozan s. yigit
@ 2002-03-18 10:38         ` ozan s. yigit
  2002-03-18 13:08           ` Wladimir Mutel
  2002-03-19  9:49           ` Douglas A. Gwyn
  1 sibling, 2 replies; 25+ messages in thread
From: ozan s. yigit @ 2002-03-18 10:38 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-15 18:40           ` Mike Haertel
@ 2002-03-18 10:38             ` ozan s yigit
  0 siblings, 0 replies; 25+ messages in thread
From: ozan s yigit @ 2002-03-18 10:38 UTC (permalink / raw)
  To: 9fans

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)


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-15 17:48         ` ozan s. yigit
                             ` (3 preceding siblings ...)
  2002-03-18 10:33           ` Thomas Bushnell, BSG
@ 2002-03-18 10:33           ` Ralph Corderoy
  2002-03-19  9:49             ` Douglas A. Gwyn
  2002-03-18 10:38           ` AMSRL-CI-CN
  2002-03-20 13:38           ` Boyd Roberts
  6 siblings, 1 reply; 25+ messages in thread
From: Ralph Corderoy @ 2002-03-18 10:33 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-15 17:48         ` ozan s. yigit
                             ` (2 preceding siblings ...)
  2002-03-18 10:32           ` Thomas Bushnell, BSG
@ 2002-03-18 10:33           ` Thomas Bushnell, BSG
  2002-03-21 11:01             ` ozan s yigit
  2002-03-18 10:33           ` Ralph Corderoy
                             ` (2 subsequent siblings)
  6 siblings, 1 reply; 25+ messages in thread
From: Thomas Bushnell, BSG @ 2002-03-18 10:33 UTC (permalink / raw)
  To: 9fans

"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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-15 17:48         ` ozan s. yigit
  2002-03-15 18:40           ` Mike Haertel
  2002-03-15 18:42           ` Mike Haertel
@ 2002-03-18 10:32           ` Thomas Bushnell, BSG
  2002-03-18 10:33           ` Thomas Bushnell, BSG
                             ` (3 subsequent siblings)
  6 siblings, 0 replies; 25+ messages in thread
From: Thomas Bushnell, BSG @ 2002-03-18 10:32 UTC (permalink / raw)
  To: 9fans

"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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-15 17:48         ` ozan s. yigit
  2002-03-15 18:40           ` Mike Haertel
@ 2002-03-15 18:42           ` Mike Haertel
  2002-03-18 10:32           ` Thomas Bushnell, BSG
                             ` (4 subsequent siblings)
  6 siblings, 0 replies; 25+ messages in thread
From: Mike Haertel @ 2002-03-15 18:42 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-15 17:48         ` ozan s. yigit
@ 2002-03-15 18:40           ` Mike Haertel
  2002-03-18 10:38             ` ozan s yigit
  2002-03-15 18:42           ` Mike Haertel
                             ` (5 subsequent siblings)
  6 siblings, 1 reply; 25+ messages in thread
From: Mike Haertel @ 2002-03-15 18:40 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-15 10:18       ` Douglas A. Gwyn
@ 2002-03-15 17:48         ` ozan s. yigit
  2002-03-15 18:40           ` Mike Haertel
                             ` (6 more replies)
  2002-03-18 10:38         ` ozan s. yigit
  1 sibling, 7 replies; 25+ messages in thread
From: ozan s. yigit @ 2002-03-15 17:48 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-14  9:56     ` macro fun [Re: [9fans] plan or side effect] ozan s. yigit
  2002-03-15 10:18       ` Thomas Bushnell, BSG
@ 2002-03-15 10:18       ` Douglas A. Gwyn
  2002-03-15 17:48         ` ozan s. yigit
  2002-03-18 10:38         ` ozan s. yigit
  1 sibling, 2 replies; 25+ messages in thread
From: Douglas A. Gwyn @ 2002-03-15 10:18 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: macro fun [Re: [9fans] plan or side effect]
  2002-03-14  9:56     ` macro fun [Re: [9fans] plan or side effect] ozan s. yigit
@ 2002-03-15 10:18       ` Thomas Bushnell, BSG
  2002-03-15 10:18       ` Douglas A. Gwyn
  1 sibling, 0 replies; 25+ messages in thread
From: Thomas Bushnell, BSG @ 2002-03-15 10:18 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 25+ messages in thread

* macro fun [Re: [9fans] plan or side effect]
  2002-03-08 17:30   ` Thomas Bushnell, BSG
@ 2002-03-14  9:56     ` ozan s. yigit
  2002-03-15 10:18       ` Thomas Bushnell, BSG
  2002-03-15 10:18       ` Douglas A. Gwyn
  0 siblings, 2 replies; 25+ messages in thread
From: ozan s. yigit @ 2002-03-14  9:56 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2002-03-21 11:01 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-19 10:57 macro fun [Re: [9fans] plan or side effect] forsyth
  -- strict thread matches above, loose matches on Subject: below --
2002-03-18 18:05 forsyth
2002-03-19  9:50 ` Douglas A. Gwyn
2002-03-18 11:22 forsyth
2002-03-18 17:37 ` Thomas Bushnell, BSG
2002-02-28 17:41 [9fans] plan or side effect David Gordon Hogan
2002-03-05  9:43 ` Boyd Roberts
2002-03-08 17:30   ` Thomas Bushnell, BSG
2002-03-14  9:56     ` macro fun [Re: [9fans] plan or side effect] ozan s. yigit
2002-03-15 10:18       ` Thomas Bushnell, BSG
2002-03-15 10:18       ` Douglas A. Gwyn
2002-03-15 17:48         ` ozan s. yigit
2002-03-15 18:40           ` Mike Haertel
2002-03-18 10:38             ` ozan s yigit
2002-03-15 18:42           ` Mike Haertel
2002-03-18 10:32           ` Thomas Bushnell, BSG
2002-03-18 10:33           ` Thomas Bushnell, BSG
2002-03-21 11:01             ` ozan s yigit
2002-03-18 10:33           ` Ralph Corderoy
2002-03-19  9:49             ` Douglas A. Gwyn
2002-03-21 11:01               ` Ralph Corderoy
2002-03-18 10:38           ` AMSRL-CI-CN
2002-03-20 13:38           ` Boyd Roberts
2002-03-18 10:38         ` ozan s. yigit
2002-03-18 13:08           ` Wladimir Mutel
2002-03-19  9:49             ` ozan s. yigit
2002-03-19  9:49           ` Douglas A. Gwyn
2002-03-19 16:01             ` ozan s yigit

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).