[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