• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: va_list and unanticipated format specifiers
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: va_list and unanticipated format specifiers


  • Subject: Re: va_list and unanticipated format specifiers
  • From: "email@hidden" <email@hidden>
  • Date: Fri, 4 Jun 2010 14:34:14 +0100

On 4 Jun 2010, at 00:49, Ken Thomases wrote:

> On Jun 3, 2010, at 8:46 AM, email@hidden wrote:
>
>> My app runs user supplied scripts.
>>
>> These scripts may contain RubyCocoa statements such as:
>> OSX::NSLog("task parameters are %@ and %@", a, b)
>>
>> These scripts may contain errors and the generated error reports may contain the likes of:
>> syntax error, unexpected tIDENTIFIER, expecting $end OSX::NSLog("task parameters are %@ and %@", a, b)
>>
>> When the error is logged the extra format specifiers trip the code.
>
>> All I need to do is sanitise those logging statements that derive from script errors and escape % as %%.
>
> I don't think that's the route you should take.  As I mentioned toward the very end of my reply, if you have a string that you need to write/log, and that string is not supposed to be treated as a format string, don't pass it as the format string.  Pass it as a value.  Pass something that you control as the format string.
>
> E.g.:
>
> NSLog(@"syntax error, unexpected tIDENTIFIER, expecting $end %@\n", arbitrary_nsstring);
>
Thanks for persisting Ken.
You are of course quite right.

I was erroneously calling my log macro as:
MLog(RELEASELOG, logError);
which is fine until logError contains format specifiers.

The correct approach is, as you point out:
MLog(RELEASELOG, @"%@", logError);

In general it would seem that when a  method/function has format + va_list signature
invocations should not contain single variable argument lists.

NSLog(someStringVar);
is unsafe.

NSLog(@"%@", someStringVar);
is safe.

Needless to say I had committed the same mistake in several other locations, so thanks again.
This was a frequent offender:
@try {
		[whatever really];
}
@catch (NSException *e) {
	NSLog([e reason]);
}

The following regex is reasonably effective at finding the issue:
NSLog\([^@]

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.com

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: va_list and unanticipated format specifiers
      • From: Ken Thomases <email@hidden>
References: 
 >va_list and unanticipated format specifiers (From: "email@hidden" <email@hidden>)
 >Re: va_list and unanticipated format specifiers (From: Ken Thomases <email@hidden>)
 >Re: va_list and unanticipated format specifiers (From: "email@hidden" <email@hidden>)
 >Re: va_list and unanticipated format specifiers (From: Ken Thomases <email@hidden>)

  • Prev by Date: Re: Notification of window visible?
  • Next by Date: Class OC_PythonObject: no such selector: _cfTypeID
  • Previous by thread: Re: va_list and unanticipated format specifiers
  • Next by thread: Re: va_list and unanticipated format specifiers
  • Index(es):
    • Date
    • Thread