[Top][All Lists]

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

Re: NSString bug with test and really dodgy patch.

From: Chris Ball
Subject: Re: NSString bug with test and really dodgy patch.
Date: Tue, 2 Oct 2012 15:30:26 -0700

> I kind of agree with your sentiments (having been bitten by that myself when 
> logging stuff), but I investigated it at the time and GSFormat.m is right and 
> your code is wrong.
> The reason is that the %s format deal with a nul terminated c-string 
> argument, and by definition that's *not* an array of char whose length is 
> determined by the precision of the format string, the nul terminator is 
> *mandatory*.  If you code passes an argument which is not nul terminated than 
> your code is doing something illegal and you can't really complain about 
> *anything* that happens.
> Also, the precision in the format works in conjunction with field width and 
> alignment ... the format code needs to determine the length of the string you 
> passed (using strlen) when it decides which part of the string to use ... so 
> in the case where the rightmost part of the string should be displayed, using 
> the precision as the length would give the wrong result.
> We could probably adapt your patch to use precision as string lengh in those 
> cases where it will work, but you can't catch all cases that way ... so maybe 
> it's better if people find out as soon as possible that c-strings have to be 
> nul terminated.
> Sorry about this ... but it's a behavior inherited from the C stdio library 
> and posix etc standards.  My own feeling is that format strings *ought* to 
> provide some way of working with unterminated strings, but they just don't, 
> so you have to copy the data into a big enough buffer, add the nul 
> terminator, and use that buffer intead of the original data :-(

Interesting, I've never read the actual standard, my copy of K&R (2nd ed.) just
says (in table B-1);

's' char *; characters from the string are printed until a '\0' is reached or
until the number of characters indicated by the precision have been printed.

So by from the way K&R reads it is a bug.  No idea about POSIX et. al. though.
I find it humorous that my book opened to exactly that page and I haven't looked
in there in quite a number of years.


reply via email to

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