Using == with char *

Discussion in 'C Programming' started by Vishal Ladha, Aug 19, 2003.

  1. Vishal Ladha

    Vishal Ladha Guest

    Hi !

    I have been experimenting with char * for a while now. I have two pieces of
    code :

    Code1 :
    =====

    char *ptr = "hello";

    if (ptr == "hello")
    {
    printf("true\n");
    }
    else
    {
    printf ("false\n");
    }

    Code2:
    =====

    char *ptr = (char *) malloc(6* sizeof(char));
    strcpy(ptr,"hello")

    if (ptr == "hello")
    {
    printf("true\n");
    }
    else
    {
    printf ("false\n");
    }


    Code1 prints true while Code2 prints false.

    Now, I know that Code1 is a pathetic way of programming and it
    will result in a segmentation fault in some memory operation(strcpy etc).

    But I have 2 questions regarding this.

    1. Why are the the answers different in Code1 and Code2. I had expected
    the answers in both the cases to be false.

    2. What is the difference between == operator and stcmp ?.
    Why doesn't == work for strings (ASCII and binary comparison ????)

    Thanks !

    Regards,
    Vishal
    Vishal Ladha, Aug 19, 2003
    #1
    1. Advertising

  2. Vishal Ladha

    Jirka Klaue Guest

    Vishal Ladha wrote:
    ....
    > char *ptr = "hello";
    >
    > if (ptr == "hello")

    ....
    > 2. What is the difference between == operator and stcmp ?.
    > Why doesn't == work for strings (ASCII and binary comparison ????)


    http://www.eskimo.com/~scs/C-faq/q8.2.html

    Jirka
    Jirka Klaue, Aug 19, 2003
    #2
    1. Advertising

  3. Vishal Ladha

    Ben Pfaff Guest

    (Vishal Ladha) writes:

    > Code1 :
    > =====
    >
    > char *ptr = "hello";
    >
    > if (ptr == "hello")
    > {
    > printf("true\n");
    > }
    > else
    > {
    > printf ("false\n");
    > }

    [...]
    > Now, I know that Code1 is a pathetic way of programming and it
    > will result in a segmentation fault in some memory operation(strcpy etc).


    It's not useful, but there's nothing wrong with it from a
    standards perspective. It certainly doesn't invoke undefined
    behavior.

    Maybe you mean that if you try to strcpy() over ptr as assigned
    above, you'll get undefined behavior. That's true. But it's
    really quite unclear to me what you actually mean.
    --
    "This is a wonderful answer.
    It's off-topic, it's incorrect, and it doesn't answer the question."
    --Richard Heathfield
    Ben Pfaff, Aug 19, 2003
    #3
  4. Vishal Ladha

    Vishal Ladha Guest

    Ben Pfaff <> wrote in message news:<>...
    > (Vishal Ladha) writes:
    >
    > > Code1 :
    > > =====
    > >
    > > char *ptr = "hello";
    > >
    > > if (ptr == "hello")
    > > {
    > > printf("true\n");
    > > }
    > > else
    > > {
    > > printf ("false\n");
    > > }

    > [...]
    > > Now, I know that Code1 is a pathetic way of programming and it
    > > will result in a segmentation fault in some memory operation(strcpy etc).

    >
    > It's not useful, but there's nothing wrong with it from a
    > standards perspective. It certainly doesn't invoke undefined
    > behavior.
    >
    > Maybe you mean that if you try to strcpy() over ptr as assigned
    > above, you'll get undefined behavior. That's true. But it's
    > really quite unclear to me what you actually mean.




    I think I have got the answer from Darrell Grainger. Here it is

    ================================================================

    Hi !
    >
    > I have been experimenting with char * for a while now. I have two pieces of
    > code :
    >
    > Code1 :
    > =====
    >
    > char *ptr = "hello";



    This line of code creates two things. The first thing is a variable ptr.
    The second thing is the string literal "hello". It then assigned the
    address of the string literal to the variable ptr. For example, if the
    compiler puts the string literal "hello" in memory location 5000 then ptr
    equals 5000.


    > if (ptr == "hello")



    The compiler could create a second string literal "hello" but a good
    compiler will know that a constant string literal "hello" already exists
    and it will use that same string for this comparison. This means that the
    string literal here *CAN* be the same memory location as the one above.

    In the case of your compiler, they are the same string. Therefore, the
    comparison will be true. It is equally possible for the comparison to be
    false. For example, the above assignment makes "hello" a constant string
    literal. Change it to:

    char ptr[] = "hello";

    and you *MIGHT* find this if statement is false.


    > {
    > printf("true\n");
    > }
    > else
    > {
    > printf ("false\n");
    > }
    >
    > Code2:
    > =====
    >
    > char *ptr = (char *) malloc(6* sizeof(char));
    > strcpy(ptr,"hello")



    In this case, ptr is being assigned the address of a writable memory
    location. The string literal "hello" *MIGHT* be read only. In all cases,
    the memory location of the malloc memory and the memory location of the
    string literal "hello" will be different.


    > if (ptr == "hello")



    Since ptr holds the address of the malloc memory and that is a different
    memory location then the string literal "hello", this will be false.


    > {
    > printf("true\n");
    > }
    > else
    > {
    > printf ("false\n");
    > }
    >
    >
    > Code1 prints true while Code2 prints false.



    Yes. Code1 can print true or false depending on the compiler. Code2 will
    always print false.


    > Now, I know that Code1 is a pathetic way of programming and it
    > will result in a segmentation fault in some memory operation(strcpy etc).



    It depends on the compiler. If your compiler places string literals, like
    "hello", in read only memory locations then attempting to alter it, via
    ptr, will result in a segmentation fault. If your compiler places string
    literals in writable memory then it will not cause a segmenttation fault.


    > But I have 2 questions regarding this.
    >
    > 1. Why are the the answers different in Code1 and Code2. I had expected
    > the answers in both the cases to be false.



    See above.


    > 2. What is the difference between == operator and stcmp ?.
    > Why doesn't == work for strings (ASCII and binary comparison ????)



    A string is a concept. There is actually no atomic data type called a
    string in C language. A string is REALLY an array of char with a '\0'
    character marking the end of the useful array. The == operator cannot be
    used to compare arrays. When you pass the name of an array to a function
    the receiving function actually receives the address of the first element.
    To be consistent, the == operator works the same way. Thus if I have:

    char s1[] = "hello";
    char s2[] = "hello";

    if(s1 == s2)
    puts("Will never get here.");
    else
    puts("This will always print");

    It is the same as:

    char s1[] = "hello";
    char s2[] = "hello";

    if(&s1[0] == &s2[0])
    puts("Will never get here.");
    else
    puts("This will always print");

    The address of the start of s1 will not be the same as the address of s2.
    The contents are the same but the memory locations are different.

    =======================================================================
    Vishal Ladha, Aug 20, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. wwj
    Replies:
    7
    Views:
    539
  2. wwj
    Replies:
    24
    Views:
    2,480
    Mike Wahler
    Nov 7, 2003
  3. Ben Pfaff
    Replies:
    5
    Views:
    458
    Tristan Miller
    Jan 17, 2004
  4. Steffen Fiksdal

    void*, char*, unsigned char*, signed char*

    Steffen Fiksdal, May 8, 2005, in forum: C Programming
    Replies:
    1
    Views:
    570
    Jack Klein
    May 9, 2005
  5. lovecreatesbeauty
    Replies:
    1
    Views:
    1,011
    Ian Collins
    May 9, 2006
Loading...

Share This Page