sprintf

[gyan]

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]

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

 

[Ico]

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

 

[Christopher Benson-Manica]

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

 

[Richard Heathfield]

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.

 

[Nelu]

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

 

[yeti]

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

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

 

[Keith Thompson]

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.

 

[yeti]

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.

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

 

[mark_bluemel]

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

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.

 

[santosh]

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

No. Just to questions regarding standard C.

 

[yeti]

No. Just to questions regarding standard C.

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

 

[Dave Hansen]

Nelu wrote:
[...attribution lost...]]

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

 

[Nelu]

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

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 .

 

[yeti]

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"

 

[Kenny McCormack]

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

 

[Walter Roberson]

Dave Hansen wrote:

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.

 

[Keith Thompson]

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?

 

[Christopher Benson-Manica]

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.

 

[Keith Thompson]

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.