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: Updated: [Patch, c* ,ObjC*] handle string objects in format checking.



On 1 Nov 2010, at 13:13, Joseph S. Myers wrote:


On Mon, 1 Nov 2010, Nicola Pero wrote:

Probably ObjC could return the constant string converted to UTF-8 so that
it can be fed into c-format.c without particular any changes to c- format.c ?

What's really wanted - to do wide string format checking for wprintf etc.
(bug 38308), not just for ObjC - are separate accessors / iterators that
in the narrow string case extract a byte, or a multibyte character, from a
string. (C format strings are complicated mixtures of bytes and multibyte
characters.) In the wide string case both would just end up extracting a
single wide character. It would be strongly desirable to have a design
for string access that is not specific to format checking but can be used
everywhere else that looks at contents of strings. (All such
optimizations - folding, built-in functions, etc. - ought to work equally
on narrow and wide strings; I don't think they do at present.)


I will no longer ask that such changes actually define the formats for
strings for non-8-bit-bytes as I did previously, and rather too
forcefully, in response to
<http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01579.html>. As long as you
set up central infrastructure for iterating over strings it will be
significantly easier for anyone adding such a target in future to define
things in one place and fix other places to use the common infrastructure.
Nor will I ask that the character set issues (bugs 20110 and 33748)
necessarily be fixed at the same time.

This looks like something beyond 4.6?


Can I ask what the position is on the original patch which sets out to check syntax and deal with two string formats which are, essentially, outside our control?

[although the basic layout and capability of CFString might well satisfy the objectives for a common string container above, and is part of the FSF code-base]

thanks,
Iain


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