NSString -> c string warning

[matt neuburg]

In <clund-E17CA6.11533517082003@amstwist00.chello.com> C Lund wrote:

> The following:
>
> char *textString;
> textString = [@"abcdefghijklmnopqrstuvwxyz" cString];
>
> gives me an "assignment discards qualifiers from pointer target type"
> warning.

Because you didn't say const. m.


--
matt neuburg, phd = [email]matt@tidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
[url]http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt[/url]
Subscribe to TidBITS. It's free and smart.

[Michael Ash]

In article <clund-E17CA6.11533517082003@amstwist00.chello.com>,
C Lund <clund@NOSPAMnotam02.no> wrote:

> The following:
>
> char *textString;
> textString = [@"abcdefghijklmnopqrstuvwxyz" cString];
>
> gives me an "assignment discards qualifiers from pointer target type"
> warning.
>
> It works the way it's supposed to, but I *am* getting a warning. Is this
> about a loss of information I don't need or a symptom of something more
> serious? Should I just ignore it?
>
> "lossyCString" gives the same result, btw.

As another poster said, you need your variable declared const, because
these methods return const strings. In other words, you're not allowed
to change the string they return.

These methods are fairly strange. They return a string pointer that is
effectively autoreleased, even though you can't autorelease things that
aren't objects. I think they make an NSData object that contains the
string, and give you the pointer to NSDatat's bytes. The point of this
is that your textString will get pulled out from underneath you whenever
the autorelease pool is popped. This may be ok for your application, but
if it's not, copy the returned string so you have control over how long
it stays.

Also, most of the time, [string UTF8String] is what you'll want to use.
This will give you ASCII codes for ASCII characters, and use a non-lossy
unicode encoding for non-ASCII characters that won't interfere with any
C-string handling routines. This lets you correctly store non-english
scripts in C strings, should you need to do so. And you never know what
the user might type into a text box.

If you know for sure that you don't have any non-ASCII, then UTF8String
and cString will be the same except possibly for performance. So why not
just use UTF8String everywhere, and you won't accidentally use cString
for something the user has control over.

Ok, this post is probably about 50% too long, so I'll stop now. :P

[C Lund]

In article <mail-52536A.10050317082003@localhost>,
Michael Ash <mail@mikeash.com> wrote:

> > char *textString;
> > textString = [@"abcdefghijklmnopqrstuvwxyz" cString];

> As another poster said, you need your variable declared const, because
> these methods return const strings. In other words, you're not allowed
> to change the string they return.

textString was to be sent to another class. Recieving it as a "const
char *" did the trick.

> Also, most of the time, [string UTF8String] is what you'll want to use.
> This will give you ASCII codes for ASCII characters, and use a non-lossy
> unicode encoding for non-ASCII characters that won't interfere with any
> C-string handling routines. This lets you correctly store non-english
> scripts in C strings, should you need to do so. And you never know what
> the user might type into a text box.

Makes sense. It makes no difference for my current use, but I might as
well make a habit of it.

--
C Lund, [url]www.notam02.no/~clund[/url]

[matt neuburg]

In <clund-136B47.18324217082003@amstwist00.chello.com> C Lund wrote:

> In article <mail-52536A.10050317082003@localhost>,
> Michael Ash <mail@mikeash.com> wrote:

>> Also, most of the time, [string UTF8String] is what you'll want to
>> use. This will give you ASCII codes for ASCII characters, and use a
>> non-lossy unicode encoding for non-ASCII characters that won't
>> interfere with any C-string handling routines. This lets you
>> correctly store non-english scripts in C strings, should you need to
>> do so. And you never know what the user might type into a text box.

>
> Makes sense. It makes no difference for my current use

Not so. Listen more attentively to what Michael is trying to tell you.
cString has been deprecated for a year now, with a warning that it may
not even be supported in future versions of the system. Never use it. It
has a dangerous feature: it relies upon the "default encoding", and you
have no way of controlling this. So cString can have different results
on different machines. m.

--
matt neuburg, phd = [email]matt@tidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
[url]http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt[/url]
Subscribe to TidBITS. It's free and smart.