On Sun, Feb 8, 2009 at 2:44 AM, Joar Wingfors <j...@joar.com> wrote: > > On Feb 7, 2009, at 7:13 PM, Michael Ash wrote: > >>> What's wrong is that they won't allow you to specify the text encoding to >>> use. The same thing is true for the *deprecated* method >>> "+stringWithCString:" by the way. >> >> That is incorrect. > > > I don't think that what I said is incorrect, at least not wrt. what I wanted > to express: Not being able to specify the encoding is probably the most > significant problem shared between these two API:s. Since it's been > established that the OP is working on ASCII data it's not a problem in his > particular case (Yay!), but it is a problem in general. > > > <snip> >> >> There's a substantial difference between simply passing data through >> unconverted and attempting to convert it but getting the conversion wrong. > > > I don't think that there is any difference, since you're *interpreting* the > data as a sequence of characters in both cases. fgets and friends are > documented to be operations on characters and strings, not bit patterns and > opaque data buffers. But perhaps best to agree to disagree at this point, I > don't think we're really getting anywhere, and this thread is really > starting to get old...
Actually, they are documented to be operations on bit patterns and opaque data buffers, because that's how characters and strings are documented to work in C. What is a string in C? A null-terminated sequence of bytes. What is a character in C? A byte. Saying that fgets doesn't let you specify the encoding is like saying that it doesn't let you tell it to stop beating its wife. It has no concept of an encoding. The idea simply does not exist there. It's like saying TextEdit doesn't let you specify the language of the document you're editing. Technically it's true: it doesn't let you do this. But it implies that it somehow chooses a language for you and you can't change that, that language settings are important. That's not true: TE doesn't care what language you use, it just passes stuff in one side and out the other. If you want to "agree to disagree", then fine, whatever, but IMO comparing an API which might in very, *very* rare cases get line endings in the wrong place to an API which will completely mangle any and all non-ASCII data just does not make very much sense. Mike _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
