You are not logged in.
Pages: 1
That's the thing about debuggers: just using one is sometimes
enough to change memory layout and such so that the bug you're
trying to find and get rid of no longer appears! I hate debuggers... ;-)
I avoid them whenever possible, and do mostly old-fashioned
debugging, by throwing in lines of code to output/log various info
at various points of processing... (Though, sometimes even THAT
is enough to cause your bug to go away, which is REALLY
frustrating... ;-))
If you post your code, I'm sure someone here will probably spot
the problem... I'm guessing you're probably just overflowing your
buffer with memcpy()... Either the target buffer, or you're reading
too far off the end of the source buffer, into unmapped memory...
Offline
Thanks for replying so fast.
After reading your reply, i changed my destination memory from --- char * --- to a char arr[10], and that worked.
//this works fine --- char oneMsg[10];
//this does not work --- char *oneMsg="sdghfkjdghfk";
I am a little puzzled by that, but certainly pleased to see it working now.
Offline
Well, yeah, if you had your destination buffer pointing to a fixed
constant string, you'd definitely have a problem... At least on any
system which sticks string literals in non-writable memory space,
anyway... They're supposed to be CONSTANTS, hence you
shouldn't be trying to overwrite them! ;-) Your destination needs
to be some valid writable buffer space: typically, either a simple
array (be it automatic stack-based or static heap-based) as you've
now gone with, or dynamically allocated heap-based memory...
Offline
Pointers to string literals should be
const char *because strings literals are constants and cannot be changed. However, very similar initialization code can be used to initialize an array that is not constant.
const char *oneMsg="sdghfkjdghfk";
Allocates space for a pointer and initializes it to point to a string literal (which is also allocated someplace but it might be unmodifiable space; strings can also be non-unique then--multiple similar looking string literals might well point into the same memory and changing such would be bad). For gcc at least you can add -Wwrite-strings and string literals will be compiled as if they are type
const char *instead of
char *. This behavior is similar to what is required by the standard in C++.
char oneMsg[]="sdghfkjdghfk";
Allocates space for a string only and makes sure it is initialized to a specific value. If you plan to modify a string you definitely want this over the former. Array types are almost always implicitly converted to pointer types and thus are usually only useful for allocation via declaration or definition.
It is possible to declare strange beasts like pointers to arrays but that is almost never useful.
Offline
Yeah, "const" is fine for some things, especially if all you have
to deal with is well-behaved/prototyped functions... But, if you
need to pass string literals around to functions prototyped to
just take "char *", it's a real pain in the ass... ;-) And, when
dealing with several years of legacy code that originated in
pre-ANSI K&R days, such as at my current job, you make do
with happily treating string literals as plain old "char *"s; you just
make DAMN sure you don't try to actually modify them... ;-)
Offline
In complex code where "char *" from many distant sources are passed around, making sure that attempts to modify string literals are expunged (especially from old code that was developed without such careful attention) is far from trivial. I have found this out from personal experience and why I suggested -Wwrite-strings, however, I am also well aware of the possible backward compatiblity problems such might cause as well. But for new code, I think it makes plenty of sense and even for older code such can be helpful for finding the sources of such bugs (if one does not mind sifting through loads of warnings to find the pertinent ones).
Offline
Pages: 1