segmentation fault

Discussion in 'C Programming' started by ramu, Feb 6, 2006.

  1. ramu

    ramu Guest

    int main(void)
    char ch='a';
    return 0;

    Why does this give segmentation fault?

    ramu, Feb 6, 2006
    1. Advertisements

  2. Because ch is a char (containing 'a'), not a string.
    If you want to print a char, tell printf so:

    #include <stdio.h> /* necessary for printf */
    int main(void)
    char ch='a';
    printf("%c\n",ch); /* note '%c' and the '\n' */
    return 0;

    If you want to print a string, provide one:

    #include <stdio.h> /* necessary for printf */
    int main(void)
    char ch[]="a"; /* a string, equivalent to
    char ch[] = {'a', 0};
    printf("%s\n",ch); /* note the '\n' */
    return 0;
    Martin Ambuhl, Feb 6, 2006
    1. Advertisements

  3. ramu

    ramu Guest

    Thanks for you answer.

    I want to know exactly how does it give segmentation fault? And can you
    explain the significance of ' \n' in the above code?

    ramu, Feb 6, 2006
  4. ramu

    Steve Summit Guest

    There is a clue in question 8.1 of the FAQ list at .
    Steve Summit, Feb 6, 2006
  5. Please provide context. How to:

    "If you want to post a followup via, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    You'll have to study your compiler/OS to get an answer to this, and that
    is off topic here (even if you said what they were).
    If printf() is not terminated by a '\n' it's not guaranteed to output
    Vladimir S. Oka, Feb 6, 2006
  6. Because the "%s" specifier tells printf that a string will be printed,
    and a string is terminated with a 0. But 'a' is a single char with no 0;
    printf will search into memory not allocated by your program for that 0,
    and that is not allowed.
    Without an end-of-line character '\n' at the end of the last output
    line, there are no guarantees about what will happen, including whether
    you will ever see that line, whether (if it appears) it will have any
    prompt on the same or next line or even be overwritten by that prompt.
    Martin Ambuhl, Feb 6, 2006
  7. The code in question was:

    char ch='a';

    The fact that the 'a' isn't followed by a '\0' isn't the issue.
    Given some plausible assumptions about how parameters are passed,
    the value of 'a' (97 on an ASCII-based system) will be interpreted by
    printf() as if it were a pointer value. So it *might* print characters
    starting at memory address 97 until it happens to run into a '\0'.
    Or it might die immediately if that address doesn't exist or is

    And that's just assuming that a character (almost certainly promoted
    to int) and a char* are passed to printf() in the same location. The
    "plausible assumptions" I mentioned above are absolutely *not*
    guaranteed by the standard, and there are real-world implementations
    where they don't apply. The *only* thing guaranteed is that the code
    invokes undefined behavior, defined as "behavior, upon use of a
    nonportable or erroneous program construct or of erroneous data, for
    which this International Standard imposes no requirements". The
    standard joke here is that it can make demons fly out your nose;
    that's obviously unrealistic, but an implementation that actually did
    that wouldn't violate the standard (just the laws of physics).

    If you want to understand why the code behaves in a particular way on
    a particular implementation, the C standard is silent on the subject;
    you might ask in a newsgroup specific to your compiler or system.
    Keith Thompson, Feb 6, 2006
  8. Because you lied to printf(). You told printf() to expect a pointer to
    a nul-terminated string, and instead passed a char.

    | Kenneth J. Brody | | |
    | kenbrody/at\ | | #include <std_disclaimer.h> |
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Feb 6, 2006

  9. Please quote enough of the previous message for context. To do so from
    Google, click "show options" and use the Reply shown in the expanded
    header. For more informatio, please go here
    If you mean "why precisely does my computer decide this is a
    segmentation fault", then you'd need to ask in a group specialising in
    your OS. As far as C is concerned, its merely a bug.
    '\n' means "print a newline".

    You should buy a decent C book, it will explain all this stuff. Usenet
    is NOT a good place to learn C.
    Mark McIntyre, Feb 6, 2006
  10. ramu

    John Bode Guest

    The %s conversion specifier expects its corresponding argument to be
    the starting address of a zero-terminated array of char. printf() is
    taking the value of 'a' (ASCII 97) and intepreting that as an address.
    The problem is that 97 is an invalid address, hence the segfault.

    You want to use the %c conversion specifier to print single characters.

    int main(void)
    char ch = 'a';
    char str[] = "a"; /* {'a', 0} */

    printf ("ch=%c, str=%s\n", ch, str);
    return 0;
    John Bode, Feb 6, 2006
  11. ASCII? What's that? And why is 97 an invalid address?

    Sounds like you haven't been programming on the DS2000 lately.
    Walter Roberson, Feb 6, 2006
  12. ramu

    John Bode Guest

    Some character encoding standard that isn't EBCDIC. Seems to be in
    widespread use. Picked as a common but arbitrary example.
    Because it's causing the segfault.
    Yeah, I haven't had to support multiple platforms for a while now.

    John Bode, Feb 7, 2006
  13. ramu

    Jordan Abel Guest

    Wrong - "Because it's not the result of an address-of operator or the
    name of an array". Any such value which does happen to be a valid
    address is only one in spite of those facts, not because of it. see also
    "Undefined Behavior" and "Passing the incorrect type to fprintf". Who
    says it's not really the address 0x12340061 that's passed (where '1234'
    is garbage)?
    Jordan Abel, Feb 7, 2006
    Walter Roberson, Feb 7, 2006
  15. ramu a écrit :
    Because you are invoking several undefined behaviours.

    "%s" expects the address of the first element of an array of initialized
    char terminated by a 0.

    Additionally, the prototype of printf() is required and is not in scope.

    #include <stdio.h>

    int main (void)
    char *ch = "a";
    printf("%s\n", ch);
    return 0;

    is fine.
    Emmanuel Delahaye, Feb 7, 2006
  16. ramu a écrit :
    There is no general reponse to this question. The program is invoking
    several undefined behaviours, meaning that the behaviour is
    unpredictable. It's generally a waste of time to try tu understand what
    happens exactly. The code is wrong, Just fix it. Period.
    This belongs to your textbook. We don't provide level 0 explanations.

    If you want a free decent C-book, try this one (it's on line)

    (sounds to be down at the moment)
    Emmanuel Delahaye, Feb 7, 2006
  17. I'm going to assume that ramu wasn't asking what '\n' (note: *not*
    ' \n') means (a new-line character), but was asking about the reason for
    it, which is a relatively subtle point.

    C99 7.19.2p2 says:

    A text stream is an ordered sequence of characters composed into
    lines, each line consisting of zero or more characters plus a
    terminating new-line character. Whether the last line requires a
    terminating new-line character is implementation-defined.

    So a program whose output is not terminated by a new-line may not work
    correctly (even if it uses fflush(stdout)). As a practical matter,
    it's not uncommon for a final partial output line to be printed and
    then overwritten by a prompt after the program terminates.

    (If ramu actually didn't know that '\n' means new-line, then you're
    right, a textbook or tutorial would be a better resource than this
    Keith Thompson, Feb 7, 2006
  18. write-protection by itself would have no effect here. read-protection
    would and is at least theoretically possible but not so widely used.

    Otherwise agree, and with the rest snipped.

    - David.Thompson1 at
    Dave Thompson, Feb 13, 2006
  19. Yes, I meant read-protected -- and an address like 97 very commonly
    *is* read-protected (at least protected from reading by any program
    without special privileges). A small program I just wrote to read a
    byte from address 97 died with a segmentation fault.
    Keith Thompson, Feb 13, 2006
  20. ramu

    Jordan Abel Guest

    Except that address could belong to the operating system, and
    "read-protection" in terms of protecting memory from being read from
    user programs is somewhat more common. Also, the address could simply
    not be mapped.
    Jordan Abel, Feb 13, 2006
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.