[RFC]: designing customizable format attributes

[Joseph S. Myers]

On Fri, 8 Jul 2005, Kaveh R. Ghazi wrote:

> I start with the assumption that we'll decide to preserve GCC's
> current internal data structures for defining each format attribute.

I start with the assumption that we absolutely do not want to hardcode the 
current datastructures into a design and force the code to keep those 
structures in future.  There's the obvious problem of enum format_lengths 
and the hardcoded arrays indexed by that enum forcing a limit on the 
number of possible length specifiers, but apart from that in general I 
think the code is at the point where too much is again hardcoded in the 
code and needs to move out to the datastructures before they are at a 
stage suitable for extensible checking.  For a start, the general sequence 
of components in a format is hardcoded rather than the structures listing 
the sequence in which to look for various types of component, and 
FMT_FLAG_SCANF_A_KLUDGE is exactly that - a kludge which hasn't yet been 
eliminated but should not be hardwired in.  In addition we know the 
datastructures will need to change significantly for proper i18n by 
storing noun phrases declined in multiple ways (at least, if not more 
complicated changes as well).

> Thoughts?

Stage 3 should be a time for concentrating on fixing bugs and getting out 
a good 4.1 compiler rather than for spending time trying to design 
elaborate new features.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)