This is the mail archive of the gcc@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: ObjC: attributes on methods



On Monday, March 11, 2002, at 12:32  AM, Ziemowit Laski wrote:
> The latter. :)  Well, I take that back -- I do recall seeing a feature 
> request like this in the internal Apple database, the final goal being 
> to have GCC type-check the arguments following the format string, just 
> as for the ordinary "C" printf and friends.  (I assume this is what 
> you're aiming at also, right?)

   Yes, but I additionally want to add support for ObjC format strings:

	[NSString stringWithFormat: @"%@", anInt];

   should produce a warning since %@ indicates an id.  This is an 
extremely common error that the compiler should check for in NSString, 
NSLog, NSException, NSRunAlertPanel, and other places (especially since 
a lot of these only get run in error conditions and people are less 
likely to have tested them -- lame, yes, but true).

> While I do see the appeal of this, I did manage to come up with a 
> wrinkle.  Suppose that you have also defined
>
> @interface Bar
> + (void) printf: (const char *)format, ...;
> @end
>
> WITHOUT the __attribute__(...) specification and then, somewhere else 
> still, you constructed the message
>
>    [someObj printf:"%s %d\n", arg1, arg2];
>
> what should the compiler do?  In the general case, it won't be able to 
> tell whether to perform the argument "type-checking" or not.

   If the compiler sees two applicable method prototypes, one with printf 
argument checking and one without and it can't make a decision on which 
is right based on the receiver type it could consider the method 
prototypes unequal and issue a warning (just like it already does for 
methods with the same selector but differing argument/result types).  
This would just extend the notion of method prototype equality to cover 
the printf attribute (I don't know what other attributes might make 
sense on ObjC method prototypes, so there may or may not be other cases 
where this would make sense).

   This would at least provide the user with some indication that there 
is a problem (even if the warning doesn't explicitly state that format 
checking might not be occurring if the method that the compiler ends up 
picking is the attribute-less version).

-tim


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