This is the mail archive of the
mailing list for the GCC project.
Re: Patch to add __builtin_printf
- To: zack at rabi dot columbia dot edu
- Subject: Re: Patch to add __builtin_printf
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Wed, 20 Sep 2000 13:15:51 -0400 (EDT)
- Cc: gcc-patches at gcc dot gnu dot org
> From: Zack Weinberg <firstname.lastname@example.org>
> >I'm about to submit patches to achieve: printf("%s",foo)->fputs(foo,stdout)
> >(Capturing stdout was the hairy part.) So that much you can count on.
> Hm... Appears to me you're working too hard. You know you are using GCC's
> preprocessor, therefore you can inject
> #undef printf
> #define printf(args...) fprintf(stdout, args...)
> at the end of stdio.h.
This starts to look like all the cruft in glibc's headers. I'd prefer
to keep what occurs in headers to a minimum and do the work inside gcc
builtins if possible.
> This doesn't help you capture putc, of course. You could also wait for (or
> help finish) the integrated preprocessor, and then dig through its symbol
> table from the front end. You'd also need a way of asking the parser 'scan
> this token list and give me the tree for it, please' - C++ can almost do
> this now, see spew.c.
Hmm, one alternative style to __builtin_initialize_stdout(stdout)
which I was looking into was "#pragma init_stdout stdout". But if
stdout was a macro, I'd haave to do exactly as you say, i.e. "scan the
token list and give me the tree for it." If there isn't already an
easy was to do it, I'm not eager to implement one, even if its mostly
Kaveh R. Ghazi Engagement Manager / Project Services
email@example.com Qwest Internet Solutions