string comparison

[Barry Schwarz]

Re: string comparison

On 9 Aug 2005 03:38:58 -0700, junky_fellow@ya hoo.co.in wrote:
[color=blue]
>Consider the following piece of code:
>char *str = "Hello";
>if (str = "Hello")
> printf("\nstrin g matches\n");
>
>str is pointer to char and "Hello" is a string literal whose
>type is "array of char".
>
>How can we compare two different objects for equality ?
>Is some conversion is being done before that comparison ?
>If yes, which conversion rule from C standard is applied here ?[/color]

After fixing the = to == in the if, the answer to your question is you
don't know if they are different objects. The compiler is allowed to
reuse string literals. It is entirely possible that str points to the
same string that is used in the if. It is also possible that str
points to a different string, even though the two strings contain same
six characters.

Just for fun, you might try
if ("Hello" == "Hello") ...

The same implementation defined behavior allows the expression to
evaluate to 1 or 0 as a result of how the compiler implements
duplicate string literals.


<<Remove the del for email>>

[Keith Thompson]

Re: string comparison

"bwaichu@yahoo. com" <bwaichu@yahoo. com> writes:[color=blue]
> char *string; /* string is a pointer */
>
> char *string = "hello"; /* string is a pointer that points to 'h' */
>
> char *string; /* declare the pointer */
> string = malloc(5); /* sets up memory to point to*/[/color]

You've allocated 5 bytes (assuming the malloc succeeds), which isn't
enough room for "hello"; you need 6 bytes to allow for the trailing
'\0'.
[color=blue]
> string = "hello"; /* assigns "hello" to memory pointed to */[/color]

No, that's a pointer assignment. The string literal refers to a
statically allocated block of 6 bytes with the value "hello\0". The
assignment causes string to point to that block. If this follows the
malloc above, you've just created a memory leak.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Krishanu Debnath]

Re: string comparison


pete wrote:[color=blue]
> Krishanu Debnath wrote:
>[color=green]
> > "Hello" has type 'array 5 of char'.[/color]
>
> (sizeof "Hello" == 6)
>
> --
> pete[/color]

Thanks for the correction.

Krishanu

[bwaichu@yahoo.com]

Re: string comparison

C strings have trailing zeros, but those are only important if you wish
to count out the length of the string or perform other string functions
after the assignment. You do not need to have the trailing zero.

My example would have been better if I used write() instead of
printf(). The trailing zero is just a C concept. The only purpose the
zero serves is to tell you where the end of the string is.

I can code a string that starts with it's size and does not terminate
with a zero. I think Pascal does strings that way.

The allocation of memory occurs either in .bss or in the heap.
The address of the string sits on the stack. You can write strings to
the stack in C, but I cannot imagine why you would want to do that.

What I do not understand is why you think I created a memory leak.
Unless I use another function that will search for the terminating
zero, I do not see the problem. For example, strcmp will search for
the terminating zero.

Brian

[Keith Thompson]

Re: string comparison

"bwaichu@yahoo. com" <bwaichu@yahoo. com> writes:[color=blue]
> C strings have trailing zeros, but those are only important if you wish
> to count out the length of the string or perform other string functions
> after the assignment. You do not need to have the trailing zero.[/color]

They're only important if you want to use C strings, which are the
most common use of character arrays in C.
[color=blue]
> My example would have been better if I used write() instead of
> printf(). The trailing zero is just a C concept. The only purpose the
> zero serves is to tell you where the end of the string is.[/color]

C concepts are what we discuss here.

[snip]
[color=blue]
> What I do not understand is why you think I created a memory leak.
> Unless I use another function that will search for the terminating
> zero, I do not see the problem. For example, strcmp will search for
> the terminating zero.[/color]

Please provide some context; don't assume that everyone can see the
article to which you're replying. I'm sick and tired of explaining
how to do this, so just search for "google broken reply link" in this
newsgroup.

Here's a fragment of the code you posted earlier:

char *string;
string = malloc(5);

string = "hello\n";

The first statement allocates a block of 5 bytes (assuming the
malloc() call succeeds) and causes string to point to the beginning of
the newly allocated block.

The second statement causes string to point to the beginning of the
string literal "hello\n" (which occupies 7 bytes). You've now lost
your only pointer to the memory allocated by malloc(), and you have no
way to release it (there's nothing you can pass to free()). That's a
memory leak.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Christian Kandeler]

Re: string comparison

bwaichu@yahoo.c om wrote:
[color=blue]
> C strings have trailing zeros, but those are only important if you wish
> to count out the length of the string or perform other string functions
> after the assignment. You do not need to have the trailing zero.[/color]

If it does not have the trailing zero, it is not a C string.
[color=blue]
> The allocation of memory occurs either in .bss or in the heap.
> The address of the string sits on the stack.[/color]

This may or may not be true, depending on your platform. And it has nothing
to do with the topic.
[color=blue]
> What I do not understand is why you think I created a memory leak.[/color]

You wrote this:

    string = malloc(5);
    string = "hello\n";

How could it be any more obvious? You are allocating five bytes of memory
and then you immediately throw away the information about where it is
stored. There now is no way for you to free it, which means you have
created a memory leak. I suspect, though, that you believe the second line
stores the "hello\n" string in the allocated memory. In that case you
definitely need to read a book on C. Not to mention that if your assumption
was true, the whole thing would be even worse as you'd cause undefined
behavior.


Christian

[Lawrence Kirby]

Re: string comparison

On Tue, 09 Aug 2005 13:34:23 +0200, Stephane Zuckerman wrote:
[color=blue][color=green]
>> I know that there's a C library function "strcmp" for string
>> comparison. What I wanted to ask is that the comparison
>> if (str == "Hello") doesn't give any compile time error.
>> Nor does it give any Warning. That means some conversion
>> should have been done because we cannot compare two objects
>> of different types.[/color]
>
> When you write
> if (a_var == "a string") { /* ... */ }
> you're really writing "is the value of a_var equals to the value of the
> address that points to the constant string 'a string' ?" So, yes, there is
> a conversion, but maybe not the one you thought...[/color]

Rather the address of the first element of the array of char defined by
the string literal.

Lawrence

[bwaichu@yahoo.com]

Re: string comparison


Keith Thompson wrote:
[color=blue]
> The second statement causes string to point to the beginning of the
> string literal "hello\n" (which occupies 7 bytes). You've now lost
> your only pointer to the memory allocated by malloc(), and you have no
> way to release it (there's nothing you can pass to free()). That's a
> memory leak.[/color]

You're right. I'm overwriting the address of the memory I had
allocated.

movq %rax, -8(%rbp)
movq $.LC0, -8(%rbp)

I shouldn't code past a certain hour.

But exit() frees memory allocated with malloc(). Is there any reason
to use free() anymore?

And yes, in practice, you should null terminate C strings or else you
will have off by one bugs.

Brian

[Chris Dollin]

Re: string comparison

bwaichu@yahoo.c om wrote:
[color=blue]
> But exit() frees memory allocated with malloc(). Is there any reason
> to use free() anymore?[/color]

Yes.

(a) I don't see any guarantee that exit() frees memory that's been
mallocated.

(b) Programs become program components.

(c) Sometimes, the total amount of memory turned over by a program
in its lifetime exceeds the amount of available memory.

(d) You'll likely end up with fragmented virtual memory and your
program will thrash.

(e) If you want a garbage-collected language, you have several to
choose from.
[color=blue]
> And yes, in practice, you should null terminate C strings or else you
> will have off by one bugs.[/color]

If it's not null-terminated, it isn't a C string.

--
Chris "electric hedgehog" Dollin
Stross won one! Farah won one! Langford won TWO!

[Keith Thompson]

Re: string comparison

"bwaichu@yahoo. com" <bwaichu@yahoo. com> writes:[color=blue]
> Keith Thompson wrote:
>[color=green]
>> The second statement causes string to point to the beginning of the
>> string literal "hello\n" (which occupies 7 bytes). You've now lost
>> your only pointer to the memory allocated by malloc(), and you have no
>> way to release it (there's nothing you can pass to free()). That's a
>> memory leak.[/color]
>
> You're right. I'm overwriting the address of the memory I had
> allocated.
>
> movq %rax, -8(%rbp)
> movq $.LC0, -8(%rbp)[/color]

Assembly listings are rarely useful here. I don't even know (or
particularly care) which assembly language you're using.

[...]
[color=blue]
> And yes, in practice, you should null terminate C strings or else you
> will have off by one bugs.[/color]

You understate the importance of the null terminator. With the '\0'
terminator, you simply don't have a string. If you have a
non-terminated character array and you try to treat it as a string,
you'll very likely get undefined behavior, which can be arbitrarily
bad.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[bwaichu@yahoo.com]

Re: string comparison

The null termination is a trademark of the string library of functions
in C. A lot of those functions are horribly written.

You can write your own string functions to replace those that are
broken like strcpy and strncpy, or you can spin your own type of
string. You will have to include object files to have any portability.

And the reason why I look at the assembly is to see how my compiler
treats the C code I write. I don't care what the standard says if all
the behaviors are not properly implemented. I know I am coding for a
gcc compiler, so I need to know how that compiler follows the
standards.

If I strictly followed the CSS2 standard, mosts pages viewed in IE
would have problems. You cannot all ways depend upon standards.

Brian

[Robert Gamble]

Re: string comparison

bwaichu@yahoo.c om wrote:

This is the third time in this thread you have posted without providing
any context and you have already been warned about this by Keith
elsethread. I know that you know how to do this because your last post
quoted context. Continual blatant disregard for basic usenet etiquette
is likely to get you plonked.
[color=blue]
> The null termination is a trademark of the string library of functions
> in C.[/color]

Null termination is part of the definition of a string. The Standard
defines a string as "a contiguous sequence of characters terminated by
and including the first null character".
[color=blue]
> A lot of those functions are horribly written.[/color]

If they are "horribly written" in your implementation, that is no fault
of the Standard, or did you mean horribly designed?
[color=blue]
> You can write your own string functions to replace those that are
> broken like strcpy and strncpy,[/color]

Please explain how these functions are "broken", on second thought,
don't.
[color=blue]
> or you can spin your own type of string.[/color]

Your own type of string? You can create anything you like and call it
a string but that doesn't make it one.
[color=blue]
> You will have to include object files to have any portability.[/color]

This makes no sense at all. Object files are inherently not portable.
[color=blue]
> And the reason why I look at the assembly is to see how my compiler
> treats the C code I write. I don't care what the standard says if all
> the behaviors are not properly implemented. I know I am coding for a
> gcc compiler, so I need to know how that compiler follows the
> standards.[/color]

This is all very well discussed in the gcc documentation, I would think
it would be a little easier to consult that than to try to pick through
the machine generated assembly code. If you don't trust the
documentation, then why trust that the assembler will generate the
machine code properly? Do you check the machine code to see if the
assembler is doing what you expect?
[color=blue]
> If I strictly followed the CSS2 standard, mosts pages viewed in IE
> would have problems. You cannot all ways depend upon standards.[/color]

You cannot depend on applications that intentionally deviate from
standards, there is a difference here.

Robert Gamble