Re: expanding __attribute__((format,..))

On Fri, 10 Nov 2006, Nuno Lopes wrote: On Fri, 10 Nov 2006, Ian Lance Taylor wrote: I kind of liked this idea: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00797.html but of course it was insane. I still think a higher level state machine as described in the followups is how

expanding __attribute__((format,..))

Hi, I've been thinking that it would be a good idea to extend the current __attribute__((format,..)) to use an arbitrary user callback. I searched the mailing list archives and I found some references to similar ideas. So do you think this is feasible? It would allow specifying arbitrary

Re: expanding __attribute__((format,..))

I've been thinking that it would be a good idea to extend the current __attribute__((format,..)) to use an arbitrary user callback. I searched the mailing list archives and I found some references to similar ideas. So do you think this is feasible? I think it would be nice. We usually founder

Re: expanding __attribute__((format,..))

On Fri, 10 Nov 2006, Ian Lance Taylor wrote: I kind of liked this idea: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00797.html but of course it was insane. I still think a higher level state machine as described in the followups is how things should be done. wouldn't that be killing a

Re: default cflags to compile

I need to generate a gcc binary that will always enable the -fabi-version=1, because I have a library built with gcc 3.3 and I need to link with it, but I would like to use gcc 4. The libstdc++ ABI broke between these releases, so unless your library doesn't use libstdc++ at all (somewhat

default cflags to compile

file to always define _GXX_ABI_VERSION as 102? Thanks in advance, Nuno Lopes