String Comparison

Discussion in 'C Programming' started by Dhruv Ahuja, Nov 1, 2004.

  1. Dhruv Ahuja

    Dhruv Ahuja Guest

    Consider:

    printf("%d", "ABC" == "ABC");

    The ANSI standard says that string comparsion using a comparison
    operator (==) is not allowed. It recommends the use of the strcmp() in
    <string.h>.

    The Borland compiled programs print "0" on this; while the GCC and MS
    VC++ compiled programs print "1".

    Which compiler, would you say, returns the most appropriate answer,
    not forgetting what the ANSI recommends...
     
    Dhruv Ahuja, Nov 1, 2004
    #1
    1. Advertising

  2. Dhruv Ahuja <> scribbled the following:
    > Consider:


    > printf("%d", "ABC" == "ABC");


    > The ANSI standard says that string comparsion using a comparison
    > operator (==) is not allowed. It recommends the use of the strcmp() in
    > <string.h>.


    It certainly does not say it is not allowed. I think what it says is
    that it will not necessarily yield the correct result based on the
    strings' content.

    > The Borland compiled programs print "0" on this; while the GCC and MS
    > VC++ compiled programs print "1".


    > Which compiler, would you say, returns the most appropriate answer,
    > not forgetting what the ANSI recommends...


    All. None. Pick one. Or more. All the ANSI standard specifies in this
    regard is that if two strings have different contents, an == comparison
    must return 0. If they have the same content, it might return either 0
    or 1, completely depending on the implementation.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-------------------------------------------------------- rules! --------/
    "Make money fast! Don't feed it!"
    - Anon
     
    Joona I Palaste, Nov 1, 2004
    #2
    1. Advertising

  3. Dhruv Ahuja

    Default User Guest

    Dhruv Ahuja wrote:
    > Consider:
    >
    > printf("%d", "ABC" == "ABC");
    >
    > The ANSI standard says that string comparsion using a comparison
    > operator (==) is not allowed.


    Please quote the standard where it says this.

    > It recommends the use of the strcmp() in
    > <string.h>.


    Yeah, if you want to get an answer that means what you think it does.

    > The Borland compiled programs print "0" on this; while the GCC and MS
    > VC++ compiled programs print "1".


    The comparison you show checks the equality of two pointers. If a
    particular compiler has reused the string literal, then indeed the
    pointers will compare because they will be the same one. If it
    generates a unique string for each literal, then they won't.

    > Which compiler, would you say, returns the most appropriate answer,
    > not forgetting what the ANSI recommends...


    As the standard doesn't recommend anything for the case you show,
    either is appropriate.


    Brian
     
    Default User, Nov 1, 2004
    #3
  4. On Mon, 01 Nov 2004 20:37:49 +0000, Joona I Palaste wrote:

    > Mark McIntyre <> scribbled the following:
    >> On 1 Nov 2004 18:55:05 GMT, in comp.lang.c , Joona I Palaste
    >> <> wrote:
    >>>All the ANSI standard specifies in this
    >>>regard is that if two strings have different contents, an == comparison
    >>>must return 0.

    >
    >> Only by coincidence, since the values of the pointers to the two will more
    >> or less have be different. I guess its possible to concieve of an
    >> implementation or mechanism where this would not be true.

    >
    > If it is, *I'd* be glad to hear of it. Wouldn't this require memory
    > behaving differently depending on which pointer it's accessed through?

    "one\0two" and "one" might compare equal with some compilers/linkers.
     
    =?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?=, Nov 1, 2004
    #4
  5. On 1 Nov 2004 18:55:05 GMT, in comp.lang.c , Joona I Palaste
    <> wrote:

    >All the ANSI standard specifies in this
    >regard is that if two strings have different contents, an == comparison
    >must return 0.


    Only by coincidence, since the values of the pointers to the two will more
    or less have be different. I guess its possible to concieve of an
    implementation or mechanism where this would not be true.

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>


    ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
     
    Mark McIntyre, Nov 1, 2004
    #5
  6. Mark McIntyre <> scribbled the following:
    > On 1 Nov 2004 18:55:05 GMT, in comp.lang.c , Joona I Palaste
    > <> wrote:
    >>All the ANSI standard specifies in this
    >>regard is that if two strings have different contents, an == comparison
    >>must return 0.


    > Only by coincidence, since the values of the pointers to the two will more
    > or less have be different. I guess its possible to concieve of an
    > implementation or mechanism where this would not be true.


    If it is, *I'd* be glad to hear of it. Wouldn't this require memory
    behaving differently depending on which pointer it's accessed through?

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-------------------------------------------------------- rules! --------/
    "Ice cream sales somehow cause drownings: both happen in summer."
    - Antti Voipio & Arto Wikla
     
    Joona I Palaste, Nov 1, 2004
    #6
  7. In article <cm66qt$1qk$>,
    Joona I Palaste <> wrote:
    >Mark McIntyre <> scribbled the following:
    >> On 1 Nov 2004 18:55:05 GMT, in comp.lang.c , Joona I Palaste
    >> <> wrote:
    >>>All the ANSI standard specifies in this
    >>>regard is that if two strings have different contents, an == comparison
    >>>must return 0.

    >
    >> Only by coincidence, since the values of the pointers to the two will more
    >> or less have be different. I guess its possible to concieve of an
    >> implementation or mechanism where this would not be true.

    >
    >If it is, *I'd* be glad to hear of it. Wouldn't this require memory
    >behaving differently depending on which pointer it's accessed through?


    Not allowed to happen. If two pointers compare equal, following them
    will give you the same object, which has to have the same value whichever
    pointer you use to get at it.

    Note that this only applies to equality conversions - it's possible to
    have two different pointers (to nonidentical strings, f'rexample) such
    that ptr1<ptr2 and ptr2<ptr1 both evaluate to false (which if pointers
    were well-ordered would imply that they were equal).
    (This can happen in a fully segmented memory model where only the offsets
    into the segment are used for inequality comparisons, which is valid
    since pointer inequality comparisons are only defined on pointers into
    the same object or array. Comparing for equal or not-equal doesn't have
    this constraint and would be required to check both segment and offset,
    coming back with not-equal in this case.)


    dave

    --
    Dave Vandervies
    Now, obviously I've picked a terrible example, ... But if I picked something
    complicated like error-diffusion, it would be... well... complicated.
    --Arthur J. O'Dwyer in comp.programming
     
    Dave Vandervies, Nov 1, 2004
    #7
  8. In article <>,
    Nils O. SelÄsdal <> wrote:

    >"one\0two" and "one" might compare equal with some compilers/linkers.


    Since we're talking about strings, which are defined as sequences of
    non-'\0' characters terminated by a '\0' character, these are the same
    string, so they're allowed to be pointed at by equal pointers.


    dave

    --
    Dave Vandervies
    Now, obviously I've picked a terrible example, ... But if I picked something
    complicated like error-diffusion, it would be... well... complicated.
    --Arthur J. O'Dwyer in comp.programming
     
    Dave Vandervies, Nov 1, 2004
    #8
  9. On 1 Nov 2004 20:37:49 GMT, in comp.lang.c , Joona I Palaste
    <> wrote:

    >Mark McIntyre <> scribbled the following:
    >> On 1 Nov 2004 18:55:05 GMT, in comp.lang.c , Joona I Palaste
    >> <> wrote:
    >>>All the ANSI standard specifies in this
    >>>regard is that if two strings have different contents, an == comparison
    >>>must return 0.

    >
    >> Only by coincidence, since the values of the pointers to the two will more
    >> or less have be different. I guess its possible to concieve of an
    >> implementation or mechanism where this would not be true.

    >
    >If it is, *I'd* be glad to hear of it. Wouldn't this require memory
    >behaving differently depending on which pointer it's accessed through?


    One trivial way to achieve this is to pass pointers between processes,
    since the same logical address could map to different physical ones. This
    is of course outside the realms of C.
    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>


    ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
     
    Mark McIntyre, Nov 1, 2004
    #9
    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. Jason
    Replies:
    2
    Views:
    27,945
    Phil Hanna
    Sep 20, 2003
  2. grz02

    Java String comparison

    grz02, Feb 23, 2005, in forum: Java
    Replies:
    40
    Views:
    15,849
    nooobody
    Mar 5, 2005
  3. Replies:
    21
    Views:
    1,457
    Alex Vinokur
    Aug 18, 2007
  4. Smithers
    Replies:
    12
    Views:
    1,209
    Ben Voigt [C++ MVP]
    Jul 7, 2009
  5. Deepu
    Replies:
    1
    Views:
    268
    ccc31807
    Feb 7, 2011
Loading...

Share This Page