sprintf

Discussion in 'C Programming' started by gyan, Jan 16, 2007.

  1. gyan

    gyan Guest

    Hi All,

    I am using sprintf and getting starnge output in following case

    char temp_rn[12];
    memset(temp_rn,'\0',12);
    sprintf(temp_rn,"0%s",temp_rn);

    the final value in temp_rn is 00
    how it is behaving like this, when source string and output string is
    same.
     
    gyan, Jan 16, 2007
    #1
    1. Advertising

  2. gyan

    yeti Guest

    Hi gyan
    When you are using memeset you are filling temp_rn will NULLs
    Thus first character of the string will be a NULL characet or in other
    words temp_rn becomes a empty string.

    Now when you are using sprintf you are changing the first character of
    temp_rn to '0' (zero). Thus at this point temp_rn has value "0" now you
    append temp_rm to itself hence it becomes "00"

    Hope that clears it

    Rohin Koul

    gyan wrote:

    > Hi All,
    >
    > I am using sprintf and getting starnge output in following case
    >
    > char temp_rn[12];
    > memset(temp_rn,'\0',12);
    > sprintf(temp_rn,"0%s",temp_rn);
    >
    > the final value in temp_rn is 00
    > how it is behaving like this, when source string and output string is
    > same.
     
    yeti, Jan 16, 2007
    #2
    1. Advertising

  3. gyan

    Ico Guest

    gyan <> wrote:
    > Hi All,
    >
    > I am using sprintf and getting starnge output in following case
    >
    > char temp_rn[12];
    > memset(temp_rn,'\0',12);
    > sprintf(temp_rn,"0%s",temp_rn);
    >
    > the final value in temp_rn is 00
    > how it is behaving like this, when source string and output string is
    > same.


    it is behaving undefined


    --
    :wq
    ^X^Cy^K^X^C^C^C^C
     
    Ico, Jan 16, 2007
    #3
  4. yeti <> wrote:

    (Please don't top post.)

    > gyan wrote:


    > > char temp_rn[12];
    > > memset(temp_rn,'\0',12);
    > > sprintf(temp_rn,"0%s",temp_rn);


    > When you are using memeset you are filling temp_rn will NULLs


    That's "NUL"; NULL is a macro which yields a null pointer constant.
    The difference is subtle but non-trivial.

    > Thus first character of the string will be a NULL characet


    That would be correct as "null character" (note capitalization).

    > Now when you are using sprintf you are changing the first character of
    > temp_rn to '0' (zero). Thus at this point temp_rn has value "0" now you
    > append temp_rm to itself hence it becomes "00"


    No. Annex J.2 of n869 describes undefined behavior, which includes

    "The snprintf, sprintf, sscanf, vsnprintf, vsprintf, mbstowcs,
    wcstombs, memcpy, strcpy, strncpy, strcat, strncat, strxfrm, or
    strftime function, or any of the functions declared by <wchar.h>
    (except where otherwise specified), is used to copy between
    overlapping objects."

    What OP was trying to do is Wrong, and the Standard allows the
    implementation to do *anything*, which includes the behavior OP
    noticed.

    --
    C. Benson Manica | I *should* know what I'm talking about - if I
    cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Jan 16, 2007
    #4
  5. gyan said:

    > Hi All,
    >
    > I am using sprintf and getting starnge output in following case
    >
    > char temp_rn[12];
    > memset(temp_rn,'\0',12);
    > sprintf(temp_rn,"0%s",temp_rn);
    >
    > the final value in temp_rn is 00
    > how it is behaving like this, when source string and output string is
    > same.


    Note in particular the last sentence of the following quote from the
    Standard:

    4.9.6.5 The sprintf function

    Synopsis

    #include <stdio.h>
    int sprintf(char *s, const char *format, ...);

    Description

    The sprintf function is equivalent to fprintf , except that the
    argument s specifies an array into which the generated output is to be
    written, rather than to a stream. A null character is written at the
    end of the characters written; it is not counted as part of the
    returned sum. If copying takes place between objects that overlap,
    the behavior is undefined.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, Jan 16, 2007
    #5
  6. gyan

    Nelu Guest

    gyan <> wrote:
    > Hi All,
    >
    > I am using sprintf and getting starnge output in following case
    >
    > char temp_rn[12];
    > memset(temp_rn,'\0',12);
    > sprintf(temp_rn,"0%s",temp_rn);
    >
    > the final value in temp_rn is 00
    > how it is behaving like this, when source string and output string is
    > same.
    >


    C99 7.19.6.6-2: "... If copying takes place between objects that
    overlap, the behavior is undefined."

    --
    Ioan - Ciprian Tandau
    tandau _at_ freeshell _dot_ org (hope it's not too late)
    (... and that it still works...)
     
    Nelu, Jan 16, 2007
    #6
  7. gyan

    yeti Guest

    Nelu wrote:

    > gyan <> wrote:
    > > Hi All,
    > >
    > > I am using sprintf and getting starnge output in following case
    > >
    > > char temp_rn[12];
    > > memset(temp_rn,'\0',12);
    > > sprintf(temp_rn,"0%s",temp_rn);
    > >
    > > the final value in temp_rn is 00
    > > how it is behaving like this, when source string and output string is
    > > same.
    > >

    >
    > C99 7.19.6.6-2: "... If copying takes place between objects that
    > overlap, the behavior is undefined."
    >
    > --
    > Ioan - Ciprian Tandau
    > tandau _at_ freeshell _dot_ org (hope it's not too late)
    > (... and that it still works...)


    Yes I agree that standard says that the behaviour is undefined but
    leaving it at that won't answer the question.
    There still should be an explination for the behaviour. Computers as
    yet don't have free will ;-)
     
    yeti, Jan 17, 2007
    #7
  8. "yeti" <> writes:
    > Nelu wrote:
    > > gyan <> wrote:
    > > > I am using sprintf and getting starnge output in following case
    > > >
    > > > char temp_rn[12];
    > > > memset(temp_rn,'\0',12);
    > > > sprintf(temp_rn,"0%s",temp_rn);
    > > >
    > > > the final value in temp_rn is 00
    > > > how it is behaving like this, when source string and output string is
    > > > same.
    > > >

    > >
    > > C99 7.19.6.6-2: "... If copying takes place between objects that
    > > overlap, the behavior is undefined."

    >
    > Yes I agree that standard says that the behaviour is undefined but
    > leaving it at that won't answer the question.
    > There still should be an explination for the behaviour. Computers as
    > yet don't have free will ;-)


    There is no C answer. The behavior is undefined; the reason for any
    particular behavior is going to depend on the implementation, and
    possibly on the phase of the moon.

    Yes, there's likely to be a specific reason for whatever behavior you
    see on a specific system under specific circumstances -- but we can't
    guess what that reason might be. The meta-answer: don't worry about
    it, just fix the code.

    --
    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, Jan 17, 2007
    #8
  9. gyan

    yeti Guest

    Keith Thompson wrote:

    > "yeti" <> writes:
    > > Nelu wrote:
    > > > gyan <> wrote:
    > > > > I am using sprintf and getting starnge output in following case
    > > > >
    > > > > char temp_rn[12];
    > > > > memset(temp_rn,'\0',12);
    > > > > sprintf(temp_rn,"0%s",temp_rn);
    > > > >
    > > > > the final value in temp_rn is 00
    > > > > how it is behaving like this, when source string and output string is
    > > > > same.
    > > > >
    > > >
    > > > C99 7.19.6.6-2: "... If copying takes place between objects that
    > > > overlap, the behavior is undefined."

    > >
    > > Yes I agree that standard says that the behaviour is undefined but
    > > leaving it at that won't answer the question.
    > > There still should be an explination for the behaviour. Computers as
    > > yet don't have free will ;-)

    >
    > There is no C answer. The behavior is undefined; the reason for any
    > particular behavior is going to depend on the implementation, and
    > possibly on the phase of the moon.
    >
    > Yes, there's likely to be a specific reason for whatever behavior you
    > see on a specific system under specific circumstances -- but we can't
    > guess what that reason might be. The meta-answer: don't worry about
    > it, just fix the code.
    >
    > --
    > 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.


    Ah I see. Perhaps then universal answer to all the questions would be
    "Refer to C standard"
     
    yeti, Jan 17, 2007
    #9
  10. gyan

    Guest

    yeti wrote:
    > Nelu wrote:
    >
    > > gyan <> wrote:
    > > > Hi All,
    > > >
    > > > I am using sprintf and getting starnge output in following case
    > > >
    > > > char temp_rn[12];
    > > > memset(temp_rn,'\0',12);
    > > > sprintf(temp_rn,"0%s",temp_rn);
    > > >
    > > > the final value in temp_rn is 00
    > > > how it is behaving like this, when source string and output string is
    > > > same.
    > > >

    > >
    > > C99 7.19.6.6-2: "... If copying takes place between objects that
    > > overlap, the behavior is undefined."
    > >
    > > --
    > > Ioan - Ciprian Tandau
    > > tandau _at_ freeshell _dot_ org (hope it's not too late)
    > > (... and that it still works...)

    >
    > Yes I agree that standard says that the behaviour is undefined but
    > leaving it at that won't answer the question.
    > There still should be an explination for the behaviour. Computers as
    > yet don't have free will ;-)


    Of course there's an explanation for the behaviour, and if you really
    wanted to, you could find it.

    And if you put in the effort, you'd find the explanation for this
    particular combination of compiler, libraries and platform. It would
    tell you precisely nothing that would be certain to apply to a
    different combination.

    I've got better things to do with my time.
     
    , Jan 17, 2007
    #10
  11. gyan

    santosh Guest

    yeti wrote:
    > Keith Thompson wrote:
    > > "yeti" <> writes:
    > > > Nelu wrote:
    > > > > C99 7.19.6.6-2: "... If copying takes place between objects that
    > > > > overlap, the behavior is undefined."
    > > >
    > > > Yes I agree that standard says that the behaviour is undefined but
    > > > leaving it at that won't answer the question.
    > > > There still should be an explination for the behaviour. Computers as
    > > > yet don't have free will ;-)

    > >
    > > There is no C answer. The behavior is undefined; the reason for any
    > > particular behavior is going to depend on the implementation, and
    > > possibly on the phase of the moon.
    > >
    > > Yes, there's likely to be a specific reason for whatever behavior you
    > > see on a specific system under specific circumstances -- but we can't
    > > guess what that reason might be. The meta-answer: don't worry about
    > > it, just fix the code.

    >
    > Ah I see. Perhaps then universal answer to all the questions would be
    > "Refer to C standard"


    No. Just to questions regarding standard C.
     
    santosh, Jan 17, 2007
    #11
  12. gyan

    yeti Guest

    santosh wrote:

    > yeti wrote:
    > > Keith Thompson wrote:
    > > > "yeti" <> writes:
    > > > > Nelu wrote:
    > > > > > C99 7.19.6.6-2: "... If copying takes place between objects that
    > > > > > overlap, the behavior is undefined."
    > > > >
    > > > > Yes I agree that standard says that the behaviour is undefined but
    > > > > leaving it at that won't answer the question.
    > > > > There still should be an explination for the behaviour. Computers as
    > > > > yet don't have free will ;-)
    > > >
    > > > There is no C answer. The behavior is undefined; the reason for any
    > > > particular behavior is going to depend on the implementation, and
    > > > possibly on the phase of the moon.
    > > >
    > > > Yes, there's likely to be a specific reason for whatever behavior you
    > > > see on a specific system under specific circumstances -- but we can't
    > > > guess what that reason might be. The meta-answer: don't worry about
    > > > it, just fix the code.

    > >
    > > Ah I see. Perhaps then universal answer to all the questions would be
    > > "Refer to C standard"

    >
    > No. Just to questions regarding standard C.

    We are talking about question where standard says "I don't know"
     
    yeti, Jan 17, 2007
    #12
  13. gyan

    Dave Hansen Guest

    yeti wrote:
    > Nelu wrote:
    >

    [...attribution lost...]]
    > > > sprintf(temp_rn,"0%s",temp_rn);
    > > >
    > > > the final value in temp_rn is 00
    > > > how it is behaving like this, when source string and output string is
    > > > same.
    > > >

    > >
    > > C99 7.19.6.6-2: "... If copying takes place between objects that
    > > overlap, the behavior is undefined."

    [...]
    > Yes I agree that standard says that the behaviour is undefined but
    > leaving it at that won't answer the question.


    The answer is "Because that's the way that particular implementation
    does it."

    > There still should be an explination for the behaviour. Computers as
    > yet don't have free will ;-)


    The standard doesn't preclude that. Computers are even allowed to have
    magical powers, and make demons fly from your nose. I'm not aware of
    any that actually do that, however.

    Regards,

    -=Dave
     
    Dave Hansen, Jan 17, 2007
    #13
  14. gyan

    Nelu Guest

    yeti <> wrote:
    >
    > Nelu wrote:
    >
    >> gyan <> wrote:
    >> > Hi All,
    >> >
    >> > I am using sprintf and getting starnge output in following case
    >> >
    >> > char temp_rn[12];
    >> > memset(temp_rn,'\0',12);
    >> > sprintf(temp_rn,"0%s",temp_rn);
    >> >
    >> > the final value in temp_rn is 00
    >> > how it is behaving like this, when source string and output string is
    >> > same.
    >> >

    >>
    >> C99 7.19.6.6-2: "... If copying takes place between objects that
    >> overlap, the behavior is undefined."

    <snip signature>
    > Yes I agree that standard says that the behaviour is undefined but
    > leaving it at that won't answer the question.


    That is the answer to the question. If it said that the behavior was
    implementation defined then you could look for an explanation in the
    implementation's documentation. In this case it's undefined.

    > There still should be an explination for the behaviour. Computers as
    > yet don't have free will ;-)


    How do you know? In the worst case scenario, for undefined behavior, they borrow it from the programmer :).


    --
    Ioan - Ciprian Tandau
    tandau _at_ freeshell _dot_ org (hope it's not too late)
    (... and that it still works...)
     
    Nelu, Jan 17, 2007
    #14
  15. gyan

    yeti Guest

    Dave Hansen wrote:

    > yeti wrote:
    > > Nelu wrote:
    > >

    > [...attribution lost...]]
    > > > > sprintf(temp_rn,"0%s",temp_rn);
    > > > >
    > > > > the final value in temp_rn is 00
    > > > > how it is behaving like this, when source string and output string is
    > > > > same.
    > > > >
    > > >
    > > > C99 7.19.6.6-2: "... If copying takes place between objects that
    > > > overlap, the behavior is undefined."

    > [...]
    > > Yes I agree that standard says that the behaviour is undefined but
    > > leaving it at that won't answer the question.

    >
    > The answer is "Because that's the way that particular implementation
    > does it."
    >
    > > There still should be an explination for the behaviour. Computers as
    > > yet don't have free will ;-)

    >
    > The standard doesn't preclude that. Computers are even allowed to have
    > magical powers, and make demons fly from your nose. I'm not aware of
    > any that actually do that, however.

    Sorry, in fact standard requires computers to have deterministic
    behaviour. There would be no standard if if demons flew from my nose.
    All lines in the standard would shrink to "How am I supposed to know.Go
    ask your computer"
    >
    > Regards,
    >
    > -=Dave
     
    yeti, Jan 17, 2007
    #15
  16. In article <>,
    yeti <> wrote:
    ....
    >Sorry, in fact standard requires computers to have deterministic
    >behaviour. There would be no standard if if demons flew from my nose.
    >All lines in the standard would shrink to "How am I supposed to know.Go
    >ask your computer"


    The dogmatic position is that the behaviour is only required to be
    deterministic in those areas covered by the standard. For anything
    outside the standard (i.e., the various "XXX defined" categories; e.g.,
    "un"defined), the behaviour can, indeed, be random (or seemingly
    determined by "free will").
     
    Kenny McCormack, Jan 17, 2007
    #16
  17. In article <>,
    yeti <> wrote:

    >Dave Hansen wrote:


    >> The standard doesn't preclude that. Computers are even allowed to have
    >> magical powers, and make demons fly from your nose. I'm not aware of
    >> any that actually do that, however.


    >Sorry, in fact standard requires computers to have deterministic
    >behaviour. There would be no standard if if demons flew from my nose.


    Within your own logic: if for a particular code situation, demons
    -always- flew from your nose, then that would be deterministic,
    and thus within the bounds of what you claim about the Standard.

    But your claim that the Standard requires computers to have
    deterministic behaviour is doubtful. The ISO C89 Rationale
    (not normative) indicates,

    Undefined behavior gives the implementor license to not catch
    certain program errors that are difficult to diagnose. It also
    identifies areas of possible conforming language extension:
    the implementor may augment the language by providing a definition
    of the officially undefined behavior.

    Thus, for any particular "undefined behavior", the implementor could
    choose to define the behavior as being non-deterministic, and that
    would be within the scope of allowed designs.

    Also, if the program does something like overwrites the end of
    a local variable, and so doing bashes control information being
    used by the implementation, then flow of control could end up
    directed to any point in memory, through any -possible- machine
    instruction sequence. That instruction sequence could include
    invoking a machine-level instruction that was defined
    non-deterministically, or even a machine-level instruction that
    was not well defined and whose operation turned out to depend upon
    random transient voltages. Similar things can happen if function
    pointers are abused -- remember the old trick of taking an
    array of integers and casting that to a function pointer and invoking
    that. If you believe that the Standard actively disallows the
    implementation from ever branching into arbitrary code, then we
    will be wanting Chapter and Verse (C&V) of the sections of the
    Standard that you believe nails down the behaviour.

    --
    Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
     
    Walter Roberson, Jan 17, 2007
    #17
  18. "yeti" <> writes:
    > santosh wrote:
    > > yeti wrote:
    > > > Keith Thompson wrote:
    > > > > "yeti" <> writes:
    > > > > > Nelu wrote:
    > > > > > > C99 7.19.6.6-2: "... If copying takes place between objects that
    > > > > > > overlap, the behavior is undefined."
    > > > > >
    > > > > > Yes I agree that standard says that the behaviour is undefined but
    > > > > > leaving it at that won't answer the question.
    > > > > > There still should be an explination for the behaviour. Computers as
    > > > > > yet don't have free will ;-)
    > > > >
    > > > > There is no C answer. The behavior is undefined; the reason for any
    > > > > particular behavior is going to depend on the implementation, and
    > > > > possibly on the phase of the moon.
    > > > >
    > > > > Yes, there's likely to be a specific reason for whatever behavior you
    > > > > see on a specific system under specific circumstances -- but we can't
    > > > > guess what that reason might be. The meta-answer: don't worry about
    > > > > it, just fix the code.
    > > >
    > > > Ah I see. Perhaps then universal answer to all the questions would be
    > > > "Refer to C standard"

    > >
    > > No. Just to questions regarding standard C.

    > We are talking about question where standard says "I don't know"


    And in that case, the correct answer is "I don't know".

    What answer other than that did you have in mind?

    --
    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, Jan 17, 2007
    #18
  19. Christopher Benson-Manica <> wrote:

    > No. Annex J.2 of n869 describes undefined behavior, which includes


    > "The snprintf, sprintf, sscanf, vsnprintf, vsprintf, mbstowcs,
    > wcstombs, memcpy, strcpy, strncpy, strcat, strncat, strxfrm, or
    > strftime function, or any of the functions declared by <wchar.h>
    > (except where otherwise specified), is used to copy between
    > overlapping objects."


    I should correct myself slightly - Annex J.2 is informative, and
    Richard Heathfield's quotation of 4.9.6.5 (which I presume to be
    normative) is therefore preferable.

    --
    C. Benson Manica | I *should* know what I'm talking about - if I
    cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Jan 17, 2007
    #19
  20. Christopher Benson-Manica <> writes:
    > Christopher Benson-Manica <> wrote:
    >
    > > No. Annex J.2 of n869 describes undefined behavior, which includes

    >
    > > "The snprintf, sprintf, sscanf, vsnprintf, vsprintf, mbstowcs,
    > > wcstombs, memcpy, strcpy, strncpy, strcat, strncat, strxfrm, or
    > > strftime function, or any of the functions declared by <wchar.h>
    > > (except where otherwise specified), is used to copy between
    > > overlapping objects."

    >
    > I should correct myself slightly - Annex J.2 is informative, and
    > Richard Heathfield's quotation of 4.9.6.5 (which I presume to be
    > normative) is therefore preferable.


    That would be 4.9.6.5 in the ANSI C89 standard, which corresponds to
    7.9.6.5 in the ISO C90 standard, and 7.19.6.6 in the C99 standard.

    I've never even seen a copy of the 1989 ANSI C standard; it was
    superseded a year later, when ANSI adopted the ISO version of the
    standard. In general, sections 4 and 5 of C89 correspond to sections
    6 and 7, respectively, of the C90 standard. C99 has the same section
    numbers, but subsections differ.

    --
    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, Jan 17, 2007
    #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. shea martin

    sprintf

    shea martin, Sep 2, 2004, in forum: Java
    Replies:
    5
    Views:
    3,631
    shea martin
    Sep 3, 2004
  2. Pep
    Replies:
    5
    Views:
    4,101
  3. CJ
    Replies:
    1
    Views:
    1,392
    Davlet Panech
    Oct 28, 2003
  4. Mike Chirico
    Replies:
    2
    Views:
    3,919
    Grumble
    Nov 19, 2003
  5. Pilatus
    Replies:
    3
    Views:
    563
    Pilatus
    Dec 18, 2003
Loading...

Share This Page