Thread: explain me this tricky qs

  1. #1
    Registered User
    Join Date
    Sep 2010
    Posts
    2

    explain me this tricky qs

    can anybody explain me the output of this question..
    problem lies in *x=x[3];
    on running it linux env it shows run time error,but i try to run it on Ideone.com | Online IDE & Debugging Tool
    and i got the output...
    Code:
    #include <stdio.h>
    #include <string.h>
    int main(){
            int i;
            char  *x="Alice";
            *x=x[3];
            for(i=0;i<=5;i++){
                    printf("%s\n",x);
                    x++;
                    }
    return(0);
    }
    Last edited by ppanda04; 09-23-2010 at 08:40 AM. Reason: for extra information

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    You are trying to modify a string literal, and that is not allowed.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Registered User
    Join Date
    Sep 2010
    Posts
    2
    can u pls try to run it in Ideone.com | Online IDE & Debugging Tool

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    You are observing the effects of undefined behaviour: sometimes it "works", sometimes it doesn't, with the latter tending to happen when your boss is around or when you are demonstrating the program to the client.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    If you're trying to learn C from reverse engineering your observations on various platforms (it works on x and not y), then you're going to have a frustrating and confusing time.

    C is full of "unspecified" and "implementation-defined" behaviour, which can and does vary from one system to another (and even within the same compiler, say between O0 and O2).

    You really have to focus on learning the language, not simply observe what any given implementation happens to do.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  6. #6
    Nasal Demon Xupicor's Avatar
    Join Date
    Sep 2010
    Location
    Poland
    Posts
    179
    This line gives me compile error in MinGW/GCC 4.5.0 (-pedantic -ansi -std=c99):
    Code:
        char* x = "Alice";
    test.c:6:15: error: initialization discards qualifiers from pointer target type
    Now if you change it to const you'll see:
    Code:
        const char* x = "Alice"; // it'll work
        *x = x[3]; // but this wont 
    test.c:7:5: error: assignment of read-only location '*x'
    So, we get back to the start, like laserlight said, you shouldn't try to modify string literal.

  7. #7
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by laserlight View Post
    You are observing the effects of undefined behaviour: sometimes it "works", sometimes it doesn't, with the latter tending to happen when your boss is around or when you are demonstrating the program to the client.
    LOL... now ain't that the truth!

  8. #8
    Registered User
    Join Date
    Sep 2007
    Posts
    1,012
    Quote Originally Posted by Xupicor View Post
    This line gives me compile error in MinGW/GCC 4.5.0 (-pedantic -ansi -std=c99):
    Code:
        char* x = "Alice";
    test.c:6:15: error: initialization discards qualifiers from pointer target type
    Unfortunately, the standard mandates that a string literal have type array of char, not array of const char. It would be wrong of a compiler to reject code that assigns a string literal to a char*; I'm not sure why your compiler is (my copy of gcc 4.5.1, unmodified, accepts it). I agree that it should be an array of const char, but due to historical reasons, I suspect, it's not.

    Of course it's always a good idea to use a const char* when pointing to a string literal, but it's not mandated by the language. By doing so, you might also find that some APIs are poorly designed, taking a char* when they should take a const char*.

  9. #9
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Well it's only been 20 years since ANSI first stated that string constants should be declared const char *

    Maybe it's time to actually start using "const char *" in new code, rather than worrying about "historic behaviour". Save that for the TurboC losers who live in the dark past.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  10. #10
    Registered User
    Join Date
    Sep 2007
    Posts
    1,012
    Well it's only been 20 years since ANSI first stated that string constants should be declared const char *
    C90 says that string literals are an array of char (6.1.4), as does C99 (6.4.5).
    Maybe it's time to actually start using "const char *" in new code, rather than worrying about "historic behaviour". Save that for the TurboC losers who live in the dark past.
    Of course programmers should use const char* when pointing to string literals. The implementation, however, is obligated (if it follows the standard) to give string literals the type “array of char”. This standard-mandated behavior is what I suspect is historical: the result of old code expecting to be able to assign string literals to char*.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Can you explain these bitwise operations?
    By 6tr6tr in forum C++ Programming
    Replies: 6
    Last Post: 10-29-2008, 01:19 PM
  2. Please explain?
    By neo_phyte in forum C Programming
    Replies: 3
    Last Post: 08-25-2006, 05:23 AM
  3. Can someone explain to me what this code means
    By Shadow12345 in forum C++ Programming
    Replies: 3
    Last Post: 12-22-2002, 12:36 PM
  4. explain this loop statement?
    By Unregistered in forum C Programming
    Replies: 2
    Last Post: 05-05-2002, 02:46 AM
  5. Can someone explain "extern" to me?
    By valar_king in forum C++ Programming
    Replies: 3
    Last Post: 09-16-2001, 12:22 AM