Re: NSString bug with test and really dodgy patch.

[Richard Frith-Macdonald]

On 3 Oct 2012, at 00:06, Stefan Bidi wrote:

> I just wanted to weight in real quick.  Chris proposed behavior is
> exactly how I wrote the CoreBase string formatting function.  I tested
> this how fprintf() works on Debian and SUSE, and came to the same
> conclusions as Chris.
> 
> I believe, more to the point, is that the call to strlen isn't needed.
> A fixed precision is already given, so why waste time looking for
> NULL?


The thing is ... strlen() is supposed to get the number of chars (bytes) ... 
and that's not what the precision part of the forrmat string tells us.

For instance, if your locale is (as on most systems nowadays) a utf-8 based 
one, a character is usually one byte but it may be more than one byte.  If the 
code assumes that a precision of 5 means a 5 byte input string, but the string 
actually contains 5 2-byte characters, then your output gets 
truncated/corrupted.

Your code may be fine, depending on what it's using the precision field for, 
but in GSFormat the code is sorting out the amount of space needed ... so it 
needs the byte-length of the input string.

Anyway, because precision is in characters and length is in bytes we can't 
assume that precision tells us length.  I guess we could write code which would 
parse the string character by character (to no more than the precision 
specified number of characters) to determine the length in bytes.  The thing is 
... do we want to go to that extra effort to more tolerantly handle the case 
where the caller has supplied an illegal argument?

Also, strlen() is efficient ... I don't know if it's a consideration in 
practice (and suspect it isn't really an issue), but more complex and slower 
code might concievably slow some applications.