segmentation fault

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

  1. ramu

    ramu Guest

    Hi,
    int main(void)
    {
    char ch='a';
    printf("%s",ch);
    return 0;
    }

    Why does this give segmentation fault?

    Regards,
    ramu, Feb 6, 2006
    #1
    1. Advertising

  2. ramu wrote:
    > Hi,
    > int main(void)
    > {
    > char ch='a';
    > printf("%s",ch);
    > return 0;
    > }
    >
    > Why does this give segmentation fault?


    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
    #2
    1. Advertising

  3. ramu

    ramu Guest

    Hi,
    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?

    Regards
    ramu, Feb 6, 2006
    #3
  4. ramu

    Steve Summit Guest

    Steve Summit, Feb 6, 2006
    #4
  5. ramu wrote:

    > Hi,
    > Thanks for you answer.


    Please provide context. How to:

    "If you want to post a followup via groups.google.com, 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
    More details at: <http://cfaj.freeshell.org/google/>

    > I want to know exactly how does it give segmentation fault?


    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).

    > And can you explain the significance of ' \n' in the above code?


    If printf() is not terminated by a '\n' it's not guaranteed to output
    anything.


    --
    BR, Vladimir

    There's an old proverb that says just about whatever you want it to.
    Vladimir S. Oka, Feb 6, 2006
    #5
  6. ramu wrote:
    > Hi,
    > Thanks for you answer.
    >
    > I want to know exactly how does it give segmentation fault?


    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.

    > And can you
    > explain the significance of ' \n' in the above code?


    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
    #6
  7. Martin Ambuhl <> writes:
    > ramu wrote:
    >> Hi,
    >> Thanks for you answer.
    >> I want to know exactly how does it give segmentation fault?

    >
    > 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.


    The code in question was:

    char ch='a';
    printf("%s",ch);

    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
    write-protected.

    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 (The_Other_Keith) <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.
    Keith Thompson, Feb 6, 2006
    #7
  8. ramu wrote:
    >
    > Hi,
    > int main(void)
    > {
    > char ch='a';
    > printf("%s",ch);
    > return 0;
    > }
    >
    > Why does this give segmentation fault?


    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 | www.hvcomputer.com | |
    | kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Feb 6, 2006
    #8
  9. On 5 Feb 2006 21:46:21 -0800, in comp.lang.c , "ramu"
    <> wrote:

    >Hi,
    >Thanks for you answer.



    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
    <http://cfaj.freeshell.org/google/>

    >I want to know exactly how does it give segmentation fault?


    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.

    >And can you
    >explain the significance of ' \n' in the above code?


    '\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.
    #

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mark McIntyre, Feb 6, 2006
    #9
  10. ramu

    John Bode Guest

    ramu wrote:
    > Hi,
    > int main(void)
    > {
    > char ch='a';
    > printf("%s",ch);
    > return 0;
    > }
    >
    > Why does this give segmentation fault?
    >
    > Regards,


    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
    #10
  11. In article <>,
    John Bode <> wrote:
    >
    >ramu wrote:
    >> int main(void)
    >> {
    >> char ch='a';
    >> printf("%s",ch);
    >> return 0;
    >> }


    >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.


    ASCII? What's that? And why is 97 an invalid address?

    Sounds like you haven't been programming on the DS2000 lately.
    --
    I was very young in those days, but I was also rather dim.
    -- Christopher Priest
    Walter Roberson, Feb 6, 2006
    #11
  12. ramu

    John Bode Guest

    Walter Roberson wrote:
    > In article <>,
    > John Bode <> wrote:
    > >
    > >ramu wrote:
    > >> int main(void)
    > >> {
    > >> char ch='a';
    > >> printf("%s",ch);
    > >> return 0;
    > >> }

    >
    > >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.

    >
    > ASCII? What's that?


    Some character encoding standard that isn't EBCDIC. Seems to be in
    widespread use. Picked as a common but arbitrary example.

    > And why is 97 an invalid address?


    Because it's causing the segfault.

    >
    > Sounds like you haven't been programming on the DS2000 lately.


    Yeah, I haven't had to support multiple platforms for a while now.

    ;-)

    > --
    > I was very young in those days, but I was also rather dim.
    > -- Christopher Priest
    John Bode, Feb 7, 2006
    #12
  13. ramu

    Jordan Abel Guest

    On 2006-02-07, John Bode <> wrote:
    >
    > Walter Roberson wrote:
    >> In article <>,
    >> John Bode <> wrote:
    >> >
    >> >ramu wrote:
    >> >> int main(void)
    >> >> {
    >> >> char ch='a';
    >> >> printf("%s",ch);
    >> >> return 0;
    >> >> }

    >>
    >> >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.

    >>
    >> ASCII? What's that?

    >
    > Some character encoding standard that isn't EBCDIC. Seems to be in
    > widespread use. Picked as a common but arbitrary example.
    >
    >> And why is 97 an invalid address?

    >
    > Because it's causing the segfault.


    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
    #13
  14. In article <>,
    John Bode <> wrote:

    >Walter Roberson wrote:
    >> In article <>,
    >> John Bode <> wrote:


    >> >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.

    >
    >> ASCII? What's that?


    >Some character encoding standard that isn't EBCDIC. Seems to be in
    >widespread use. Picked as a common but arbitrary example.


    >> And why is 97 an invalid address?


    >Because it's causing the segfault.


    There is nothing in C that would prevent 'a' from having
    the value 0x00B00001 (imagine the upper 16 bits contains the flags,
    isupper, isgraphic, isalnum, and the lower 16 bits containing the
    relative offset of characters that meet that flag combination).
    There is nothing in C that would prevent 0x00B00001 from being a valid
    int-aligned address -- int addresses do not -have- to be even
    (e.g., sizeof(char) == sizeof(int)). So the real problem could be,
    for example, that 'a' happens to correspond to an address in a segment
    owned by the user but with an execute-only attribute.

    Even if ASCII did happen to be the character set in use, 97 could
    be a valid int address, especially on machines that automatically
    trap unaligned fetches and transparently rerun them a byte at a time.

    So although your answer might have been correct about what happened
    on the OP's machine, it isn't -exactly- the right answer in terms of C.
    --
    "It is important to remember that when it comes to law, computers
    never make copies, only human beings make copies. Computers are given
    commands, not permission. Only people can be given permission."
    -- Brad Templeton
    Walter Roberson, Feb 7, 2006
    #14
  15. ramu a écrit :
    > Hi,
    > int main(void)
    > {
    > char ch='a';
    > printf("%s",ch);
    > return 0;
    > }
    >
    > Why does this give segmentation fault?
    >
    > Regards,
    >


    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.

    --
    A+

    Emmanuel Delahaye
    Emmanuel Delahaye, Feb 7, 2006
    #15
  16. ramu a écrit :
    > I want to know exactly how does it give segmentation fault?


    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.

    > And can you
    > explain the significance of ' \n' in the above code?


    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)

    http://publications.gbdirect.co.uk/c_book/

    (sounds to be down at the moment)

    --
    A+

    Emmanuel Delahaye
    Emmanuel Delahaye, Feb 7, 2006
    #16
  17. Emmanuel Delahaye <> writes:
    > ramu a écrit :
    >> I want to know exactly how does it give segmentation fault?

    >
    > 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.
    >
    >> And can you
    >> explain the significance of ' \n' in the above code?

    >
    > This belongs to your textbook. We don't provide level 0 explanations.


    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
    newsgroup.)

    --
    Keith Thompson (The_Other_Keith) <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.
    Keith Thompson, Feb 7, 2006
    #17
  18. On Mon, 06 Feb 2006 08:24:34 GMT, Keith Thompson <>
    wrote:
    <snip>
    > The code in question was:
    >
    > char ch='a';
    > printf("%s",ch);
    >
    > 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
    > write-protected.
    >

    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 worldnet.att.net
    Dave Thompson, Feb 13, 2006
    #18
  19. Dave Thompson <> writes:
    > On Mon, 06 Feb 2006 08:24:34 GMT, Keith Thompson <>
    > wrote:
    > <snip>
    >> The code in question was:
    >>
    >> char ch='a';
    >> printf("%s",ch);
    >>
    >> 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
    >> write-protected.
    >>

    > write-protection by itself would have no effect here. read-protection
    > would and is at least theoretically possible but not so widely used.


    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 (The_Other_Keith) <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.
    Keith Thompson, Feb 13, 2006
    #19
  20. ramu

    Jordan Abel Guest

    On 2006-02-13, Dave Thompson <> wrote:
    > On Mon, 06 Feb 2006 08:24:34 GMT, Keith Thompson <>
    > wrote:
    > <snip>
    >> The code in question was:
    >>
    >> char ch='a';
    >> printf("%s",ch);
    >>
    >> 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
    >> write-protected.
    >>

    > write-protection by itself would have no effect here. read-protection
    > would and is at least theoretically possible but not so widely used.


    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
    #20
    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. Alex Hunsley
    Replies:
    17
    Views:
    863
  2. Pud
    Replies:
    0
    Views:
    573
  3. Replies:
    0
    Views:
    525
  4. Ivan Vecerina
    Replies:
    0
    Views:
    482
    Ivan Vecerina
    Jun 29, 2003
  5. Vasileios Zografos

    Re: segmentation fault exception handling

    Vasileios Zografos, Jun 30, 2003, in forum: C++
    Replies:
    5
    Views:
    15,593
    Pete Becker
    Jul 1, 2003
Loading...

Share This Page