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 char codes and also arbitrary number of
required arguments. It would be nice if it could also import the attributes
from other defined callbacks.
E.g.:
#define my_format_callback(x,params)
(import printf),
("%v",zval**, size_t),
("%foo", void*)
int my_printf(char *format, ...)
__attribute__((format,("my_format_callback")))
Thanks in advance,
Nuno
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 on trying to provide a facility which can replace the builtin printf support, since printf is very complicated. Thanks for your quick answer. I'm glad that you are receptive to this problem. I kind of liked this idea: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00797.html but of course it was insane. And then there was this idea, which I think was almost workable: http://gcc.gnu.org/ml/gcc/2005-08/msg00469.html But nobody really liked it. IMHO, those two seem way too difficult to use... So you need to find something which is on the one hand very simple and on the other hand able to support the complexity which people need in practice. I sent you some kind of proposal in the last e-mail (very LISP like, unfortunately), but it seems somewhat good. I'm a PHP developer and this feature would be really great for us, as currently I do maintain a php script (regex-based) to do this kind of verifications (and a few more, like checking for use of uninitialized vars). But "parsing" C with regexes is kinda painful and error prone. Nuno
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 mosquito with a bomb? :) (unless of course we can find a simple description language) The first step (or the first hundred steps) would need to be a series of small incremental patches moving all the existing logic about format string structure from the code into more generic datastructures. In so doing you need to consider how xgettext could be made to extract a superset of the possible diagnostic sentences so that i18n for the format checking messages can work properly again (which requires that full sentences be passed to xgettext and be known by the translators, while maintainability of the format descriptions requires that the information about valid combinations be maintained at a different level more like that used by the present datastructures). Once the datastructures are suitably general, then interfaces to them can be considered. Can I do anything to help? I mean, can you point me the files and what should I do in order to make this move forward? (the most I've made was a few little patches to make a customized cross-compiler to a mips robot, so I'm not very familiarized with the code...) Regards, Nuno
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 things should be done. wouldn't that be killing a mosquito with a bomb? :) (unless of course we can find a simple description language) Format checking is complicated. Over 5% of all the 4 or so test assertions in a gcc testsuite run are from format checking testcases. Format checking is one of the most difficult parts of the compiler to get correct from an i18n perspective (i.e. having all complete sentences available for translation); everything else in the C front end apart from parse errors should be correct in that regard. Can I do anything to help? I mean, can you point me the files and what should I do in order to make this move forward? (the most I've made was a few little patches to make a customized cross-compiler to a mips robot, so I'm not very familiarized with the code...) c-format.[ch]. Understand the logic in there as a whole. Consider what aspects of information about format strings are embedded in the code and how you might improve the datastructures, one aspect at a time, to describe that aspect in data rather than code. For verifying there are no unintended changes in the compiler's behavior, compare the exact diagnostic texts in gcc.log from test runs before and after each change. OK, thanks for your tips. I'll take a look at it as soon as I have some free time (aka as soon as this university semester ends). Nuno
default cflags to compile
Hi, 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. Is there a simple way to do this (a configure option,..) ? or do I need to patch the gcc/c-cppbuiltin.c file to always define _GXX_ABI_VERSION as 102? Thanks in advance, Nuno Lopes
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 unlikely), there is little point to this.q The problem is that we are using a closed-source library from Sony (for their robots AIBO, which run on a MIPS) and they don't support anything other than gcc 3.3. If the library uses libstdc++, does it help if I compile it with -fabi-version? I have added that option to the environment of the build script. Is there a simple way to do this (a configure option,..) ? or do I need to patch the gcc/c-cppbuiltin.c file to always define _GXX_ABI_VERSION as 102? The latter, as far as I know. OK, I'll add that patch to our patchset. Nuno
