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 04:37, Nicola Pero wrote:



The actual scanning of the format strings is now local to ObjC
(there's a stub routine added by the patch) and additions to carry
that out would fall under whatever rules Mike wishes to invoke.

Wouldn't we reuse the existing routines and simply add %@ ?

Hm.
I think to double-check the doc.
IIRC there were some subtle differences from c. (on NeXT, at least)...

"NSString uses a format string whose syntax is similar to that used by other formatter objects.
It supports the format characters defined for the ANSI C function printf(), plus %@ for any object
(see “String Format Specifiers” and the IEEE printf specification)."


In attach is a draft patch I had produced during the weekend - it works for me with the GNU runtime on top
of my other patches (but it doesn't include documentation (and not enough comments), has a few hacks and
rough edges, most likelyl won't work on Darwin and it doesn't do Objective-C++ yet). ;-)

May I suggest a possible amalgamation sth like this:


(1) the patch I proposed (which handles the other necessary cases for NeXT and Darwin as well).

(2) merge your adjustments to the NSString format declaration.

add a call to objc that determines if an NSString can be represented in a manner parse-able in c-format.c

if so then it can continue to parse the literal as per the existing code (with the addition of the %@)
otherwise parse in ObjC.


This is because the string literal behind an NS (or CF) string need not be ascii or even utf8 -- it could be utf16 (although we haven't implemented that yet).

I'm not sure that we shouldn't just keep the whole thing in ObjC (and add an objc-format.c file to deal with the future expansion).

In any event, have you any objection to first applying the syntax and parsing logic - assuming Joseph is now happy with it (since that patch is already reviewed twice) and then filling in the implementation?

cheers,
Iain


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