discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with localized


From: Sebastian Reitenbach
Subject: Re: Problem with localized
Date: Sun, 29 May 2011 16:39:06 +0200
User-agent: SOGoMail 1.3.7

 
Hi,

On Sunday, May 29, 2011 15:29 CEST, David Chisnall <theraven@sucs.org> wrote: 
 
> On 29 May 2011, at 14:07, Dr. H. Nikolaus Schaller wrote:
> 
> > just guessing: %s is the formatting specified for a C string while %@ 
> > expects an NSString...
> > 
> > If %s is applied to a NSString, it tries to interpret the iVars of the 
> > NSString object as characters, aka "garbage".
> 
> 
> If you're lucky, and there is a 0 byte somewhere near the start of the object 
> - otherwise it will crash.

Thank you both for the ansewr, I seemed to have been lucky, it never crashed, 
but showed me differnt garbage every time, exchanging the %s with an %@, fixed 
it ;) I should have seen the problem by myself, but was just blind to see the 
obvious.

> 
> When using a recent compiler, GNUstep sets some attributes that make it 
> possible to check this sort of thing at compile time.  The correct way of 
> doing this is to use the English (or your favourite other language) string as 
> the name of the string, so you do:
> 
>       [NSString stringWithFormat: _(@"%s seems to be running for the first 
> time.\nPlease check the settings before you commence work"), APP_NAME],
> 
> The method that _() expands to declares that any string that it may be used 
> as a format string anywhere that the input string may be used.  You'd then 
> get a compile-time warning saying that %s expects a C string but you provided 
> it with an object.  Similarly, you'd have see an obvious error if your 
> strings file contained something like this:
> 
> "%@ some English words" = "%s some other words"
> 
> You should actually be seeing an error with this usage, saying that the 
> second argument to  -stringWithFormat: is an object but there is no 
> corresponding format specifier.  I'm a bit surprised that you don't.  The 
> usage @"AppController.running" is wrong, since this lookup function will 
> return its input if it can't find the strings file.
> 
> We could probably add some extra checking in the NSBundle code that looks up 
> the format strings to ensure that the input and output format strings match.  
> Alternatively, we could add a verify_strings tool that -make could run 
> automatically, checking format string agreement.

Thanks for the explanation, I'll keep that in mind for the future. For 
burn.app, I keep it as is, but now with %@ in place.

cheers,
Sebastian

> 
> David
> 
> -- Sent from my PDP-11 
 
 
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]