How to explain this behavior of sprintf?

Question

So the case was simple: I needed to add a character in front of a c string.

So I had my code:

char *a = "2233b";
char output[100];   
char toAdd = '-';

strcpy(output, a);
printf("\noutput=%s", output);
sprintf(output, "%c%s",  toAdd, a);
printf("\noutput=%s", output);

And the output was as expected:

output=2233b
output=-2233b

Ok, so far so good. Now the case changed and I wanted to add more characters before a c string, so I configured the code like so:

char *a = "2233b";
char output[100];   
char toAdd = '-';

strcpy(output, a);
printf("\noutput=%s", output);
sprintf(output, "%c%s",  toAdd, a);
printf("\noutput=%s", output);
sprintf(output, "%c%s",  toAdd, output);
printf("\noutput=%s", output);

I expected the output to be:

output=2233b
output=-2233b
output=--2233b

But this was not the case and the following output was printed on my screen:

output=2233b
output=-2233b
output=-------

Check working example here

Why is does output contain this value?
Because the format is just the character (%c) toAdd ('-') and a string (%s) which is output and contains ("-2233b").

So why isn't the last output containing "--2233b"? And how come the characters of output are all converted to '-'?

Check out this answer http://stackoverflow.com/questions/1973572/can-the-input-and-output-strings-to-sprintf-be-the-same — Abhishek Vasisht, Jul 06 '15 at 13:54
Side note: to add a character in front of a c string: `memmove(&output[1], &output[0], strlen(output) + 1); output[0] = toAdd;` — chux - Reinstate Monica, Jul 06 '15 at 15:43

score 3 · Answer 1 · answered Jul 06 '15 at 13:47

3

I believe the issue is in

 sprintf(output, "%c%s",  toAdd, output);

Here, you're reading from and writing to output, in a single sequenced statement. This invokes undefined behaviour.

To quote C11, chapter §7.21.6.6, the sprintf() function

If copying takes place between objects that overlap, the behavior is undefined.

answered Jul 06 '15 at 13:47

Sourav Ghosh

133,132
16
183
261

1

Uh, sorry realized to late that you already posted an answer. – lord.garbage Jul 06 '15 at 13:52
Yep, I falsely assumed this wouldn't be a problem. Another prove to myself that the full documentation of a apparently simple function is more beneficial than I might think. Thanks for clarifying! – moffeltje Jul 06 '15 at 13:55
1

@brauner no issues, :-) – Sourav Ghosh Jul 06 '15 at 13:56
@moffeltje Well, as we can see, we should not assume. You're welcome, BTW. :-) – Sourav Ghosh Jul 06 '15 at 13:56
@SouravGhosh assumptions are deadly, isn't it? – moffeltje Jul 06 '15 at 13:58
1

@moffeltje I should say , yes, at least, __most__ of the times. Better, read the docs and be sure, say goodbye to "assumptions." :-) – Sourav Ghosh Jul 06 '15 at 14:00
@moffeltje: `sprintf` is hardly a simple function :P – MicroVirus Jul 06 '15 at 14:06

score 1 · Answer 2 · answered Jul 06 '15 at 13:51

This is invoking undefined behavior as is mentioned on the corresponding man page on *nix systems and in the C and also in the POSIX standard.

NOTES
   Some programs imprudently rely on code such as the following

       sprintf(buf, "%s some further text", buf);

   to append text to buf.  However, the standards explicitly  note  that  the
   results are undefined if source and destination buffers overlap when call‐
   ing sprintf(), snprintf(), vsprintf(), and vsnprintf().  Depending on  the
   version  of  gcc(1) used, and the compiler options employed, calls such as
   the above will not produce the expected results.

   The glibc implementation of the functions snprintf() and vsnprintf()  con‐
   forms  to  the  C99  standard,  that is, behaves as described above, since
   glibc version 2.1.  Until glibc 2.0.6, they would return -1 when the  out‐
   put was truncated.

score 1 · Accepted Answer · answered Jul 06 '15 at 13:51

1

The standard prohibits passing buffers that overlap for input and output, so the behavior is undefined.

If you are interested in finding out why you get multiple dashes, here is what's going on: the problem is that when you pass output as an input to sprintf, the function behaves like a dog chasing its own tail: it writes the first character into output before reading its first character, and then its writing "front-runs" its reading as it tries, unsuccessfully, to process the %s format: new characters get added to the output right at the point where the function is reading.

To fix this problem, make a temporary copy of output before passing it to sprintf.

answered Jul 06 '15 at 13:51

Sergey Kalinichenko

714,442
84
1,110
1,523

Well, that makes sense actually. Did you just assume this is the case (because what else could it be, huh?) or did you take a look at the source code? – moffeltje Jul 06 '15 at 13:58
1

@moffeltje I did not look up the source code, I just tried to think through implementing `sprintf` myself, and how my implementation would behave in a situation like this. – Sergey Kalinichenko Jul 06 '15 at 14:02

How to explain this behavior of sprintf?

3 Answers3