Re: Updated: [Patch, c* ,ObjC*] handle string objects in format checking.

[IainS <developer at sandoe-acoustics dot co dot uk>]

On 31 Oct 2010, at 19:59, 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)...

> > (I also believe we need to take care not to paint ourselves into a
> > corner tho' - since the Apple version of ObjC does not define this
> > operation yet).
>
> What do you mean ?  __attribute__((format (NSString, 1, 2))) works
> on Apple (using LLVM I think, I don't have an Apple but I know it's
> there) and it works as expected.  The standard example is NSLog
> (in much the same way as the standard example of the printf format
> is printf) and that is very well-defined.  GNUstep has NSLog and I  
> can't
> wait for the compiler to check that the arguments passed to NSLog
> match the format string. ;-)

Hm - maybe sth LLVM-specific.. I've not looked too hard at that code.

I've got the latest XCode on Darwin 9 & 10...

apple gcc-4.2.1 (darwin9 & darwin10) both accept .... format(__  
NSString__ ... and barf on ... format(NSString ...

AFAICT it does not check the string when __ NSString__ is used. [-Wall]

and, as Joseph prompted me to check, the ObjC doc. (at least the copy  
I d/loaded) does not specifically refer to this attribute.

If you can get it to work with the test-suite additions from the patch  
- or point me at somewhere that publishes an expectation
- pls. send me the relevant info offlist.

(I don't believe it makes any difference to our game-plan -- it's  
actually helpful if it is specified for NeXT).

cheers
Iain