Groovy hepcat softwindow was jivin' on 27 Feb 2007 07:25:48 -0800 in
comp.lang.c.
could you help me about this problem?'s a cool scene! Dig it!
That should be:
No such header. It should be:
Here you create a string literal of one character length, resulting
in two bytes being allocated (one for your single character, and one
for the terminating '\0'). This may be placed in memory marked as
being readable but not writable. String literals are not modifiable.
And here you attempt to read an arbitrarily long string (likely more
than one character) into the non-modifiable, one character long string
literal, thus attempting to not only modify a non-modifiable object,
but actually overflow that, writing to memory you don't own; possibly
memory that doesn't even exist! BANG! And your program crashes. Or it
goes on "working", but ends up doing weird things to your hard drive.
Or it makes demons fly out of your nose.
Had you read the FAQ list of this newsgroup or simply lurked here
for a while you would know that scanf() is not the best thing to use
for interactive input. It is customary, upon first entering a
newsgroup, to read a month or two of articles (lurk) before posting
and to seek out and read the newsgroup's FAQ, if it has one. Failing
to do so before posting is very rude! Please read the FAQ
(
http://www.eskimo.com/~scs/C-faq/top.html) before posting any more.
What is the user supposed to be enterring anyhow? A prompt would be
helpful.
Don't cast the return from malloc(). Do check the return from
malloc().
Don't cast the return from malloc(). Do check the return from
malloc().
Here you copy the address of your string literal to your struct
member. Thus, your struct member will point to your string literal. No
other storage has been set aside, and no data copied.
A bit dodgy! I think it will probably work, since the else clause is
not executed first time around (because head == NULL first time
through the loop). But it doesn't look good to dereference tail above
the point where you actually set it to a useful value..., assuming p
actually does contain a useful value.
And again you attempt to write X characters (where X is some unknown
number) to a one character long string literal.
Check the return value. It's always a good idea.
And here you're trying to free memory that was not allocated by
malloc(), calloc() or realloc(). BANG! More undefined behaviour! More
nasal demons! Remember, the nms member of your structure points at a
string literal.
And once again, BANG! You're dereferencing ptr after freeing the
memory it points at.
return 0;
Think again! There are many problems here. There may be some I
haven't spotted; after all, I only gave your code a cursory look. Even
so, I still found many serous errors.
Because it's so severely broken.
--
Dig the even newer still, yet more improved, sig!
http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?