This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add __attribute__((format(wprintf, 2, 3))) etc. format checking support


On Fri, Dec 14, 2001 at 07:48:27PM +0000, Joseph S. Myers wrote:
> Improve the generic checking, then.  Also try to work out some way of 
> checking for duplicate messages in the test harness so a test can be added 
> for this - there are other bugs for which such a test facility would be 
> useful (e.g., when you give an invalid argument to -std, c/2896).

Ok, will do.

> Before such wide string format support can go in, I want the following
> properly resolved (and failed to get them resolved on the lists when I
> tried before):

I don't see why this all needs to be a precondition of wide format checking.
>From what I saw in c-format.c, it needs very limited subsect of such
knowledge.

> * What is the format of STRING_CSTs representing narrow strings on systems
> where target bytes are wider than host bytes?  The target bytes may be a
> multiple of host bytes (e.g. C4X), or may not be (e.g. PDP10).  They must
> represent all values of that type.  Several existing places in the
> compiler, that presume them to be the same, must be adapted.  This
> includes defining the interface of some target macros in terms of whether
> they take a count of host bytes or of target bytes.

Current STRING_CST format doesn't allow all possible values stored if target
char is wider than host char, otherwise all should work well, but is
supporting all possible values in string literals really neccessary?
If yes, then IMHO the best way would be just to represent them as
CONSTRUCTOR (as soon as we encounter the first character unrepresentable in
hosts character).

> * What is the format of wide STRING_CSTs in such cases?

Each host character represents target's BITS_PER_UNIT bits of the wide
character, their order depends on BYTES_BIG_ENDIAN.

> * How wide a target byte need we support?  Can it be wider than 
> HOST_WIDE_INT?  Can it be wider than HOST_WIDEST_INT?
> 
> * Likewise, for target wchar_t?  In both cases, GCC should fail to build 
> if the types are too wide.
> 
> * As above, where the target hardware byte is smaller than the target C 
> char (BITS_PER_UNIT smaller than CHAR_TYPE_SIZE).  There are no such 
> systems currently in tree.  If we don't really support them, we should say 
> so.

Yes.

> * Then, there should be common functions used throughout the tree for
> accessing individual elements of both narrow and wide strings.  They
> should not be specific to format checking.

There should be common functions, depending on whether we support wchar_t
wider than HOST_WIDE_INT they should either return a tree or HOST_WIDE_INT.

If the latter, format checking can use it, but if the former, IMHO using
such functions for format checking would be huge overkill when c-format is
only interested in values L'\0' and L' ' - L'~' range at most.

> > +  if (info.format_type == wcsftime_format_type && info.first_arg_num != 0)
> > +    {
> > +      error ("wcsftime formats cannot format arguments");
> > +      *no_add_attrs = true;
> > +      return NULL_TREE;
> > +    }
> 
> Get rid of this hardcoding of a name of a particular format type and use
> the structures providing information about the formats, to do this for
> both strftime and wcsftime (moving declarations about the file if
> necessary for this).

Ok.

> > +  /* Wide string version.  */
> > +  FMT_FLAG_WIDE = 256
> 
> I think it would be better for each table entry to be able to specify both
> wide and narrow names for this format, or only one if only one of wide and
> narrow is supported, rather than duplicating like this.

Ok.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]