By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,933 Members | 1,574 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,933 IT Pros & Developers. It's quick & easy.

Does wrong format specifier leads to memory corruption?

P: n/a
Hi,

We are having memory corruption in our application somewhere, unable to find
out.
one part of code we found that we are specifying wrong format specifier.

Could anyone let me know if the following code may cause memory corruption.
#include <stdio.h>
#include <string.h>
int main()
{
char str[100]={0};
strcpy(str,"temporary");
char str2[100]={0};
sprintf(str2,"%S",str); // this line should have had %s instead of %S
return 0;
};

TFH
ishekara


Nov 14 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
"indushekara" <in*********@gmail.com> wrote:
Could anyone let me know if the following code may cause memory corruption. sprintf(str2,"%S",str); // this line should have had %s instead of %S


Since using an invalid conversion specifier causes undefined behaviour,
in theory this could cause memory corruption. I'd be rather surprised if
it did, though. I'd expect it either to work as if you'd written "%s",
to write a literal "%S" to the string, to use "%S" as an implementation-
specific specifier, perhaps for a special kind of string (capitalised?
Who knows), or maybe to fail in a relatively innocuous way, possibly by
writing nothing at all.
Writing to unrelated memory, or crashing past the end of the array, or
something similar, is a theoretical, but IMO unlikely possibility. Your
error is probably elsewhere.

Richard
Nov 14 '05 #2

P: n/a
On Wed, 22 Jun 2005 15:07:28 +0530, "indushekara"
<in*********@gmail.com> wrote:
Hi,

We are having memory corruption in our application somewhere, unable to find
out.
one part of code we found that we are specifying wrong format specifier.

Could anyone let me know if the following code may cause memory corruption.
#include <stdio.h>
#include <string.h>
int main()
{
char str[100]={0};
strcpy(str,"temporary");
char str2[100]={0};
sprintf(str2,"%S",str); // this line should have had %s instead of %S
return 0;
};

Not likely. Does the actual code you've posted cause memory
corruption? My first guess is that the compiler is treating %S as %s,
and that the real code is using an unterminated str, or at least
strlen(str) > sizeof str2 - 1.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 15 '05 #3

P: n/a
Alan Balmer wrote:
<in*********@gmail.com> wrote:

.... snip ...
sprintf(str2,"%S",str); // this line should have had %s instead of %S
return 0;
};


Not likely. Does the actual code you've posted cause memory
corruption? My first guess is that the compiler is treating %S as
%s, and that the real code is using an unterminated str, or at
least strlen(str) > sizeof str2 - 1.


The compiler is probably not thinking about it at all, but just
passing it onwards to the library routines to decode. The OP
should be able to track its actions completely with a debugger, and
compare with the actions with the correct specifier.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

Nov 15 '05 #4

P: n/a
On Wed, 22 Jun 2005 18:17:07 GMT, CBFalconer <cb********@yahoo.com>
wrote:
Alan Balmer wrote:
<in*********@gmail.com> wrote:
... snip ...
sprintf(str2,"%S",str); // this line should have had %s instead of %S
return 0;
};


Not likely. Does the actual code you've posted cause memory
corruption? My first guess is that the compiler is treating %S as
%s, and that the real code is using an unterminated str, or at
least strlen(str) > sizeof str2 - 1.


The compiler is probably not thinking about it at all, but just
passing it onwards to the library routines to decode.


Quite right. Sloppy writing on my part. s /compiler/runtime/.
The OP
should be able to track its actions completely with a debugger, and
compare with the actions with the correct specifier.


Or just correct the specifier and see if it stills clobbers the
memory.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 15 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.