why are you trying to call CREATE with 0 or a negative number anyway? C will
let you shoot yourself in the foot if you let it. That is the beauty of the
language. You can do a lot of crazy crap and get away with it, especially if
you know that you want to do the crazy crap. Just put a check and a log()
statement before the CREATE you are worried about and fix it.
--Angus
______________________________ Reply Separator _________________________________
Subject: [CODE] CREATE() buglet
Author: INTERNET:CIRCLE@POST.QUEENSU.CA at CSERVE
Date: 7/7/98 3:36 AM
George <greerga@CIRCLEMUD.ORG> wrote:
>Well, if you ask for 0 bytes, you should write 0 bytes to what you get. :)
It's the implimentation dependant result of malloc(0) that bothers me.
If you ask for 0 bytes, some systems will give you an error (NULL result),
while others will happily let you scribble into whatever happens to be
after that 0th byte. If we are looking for maximum portability, we
should force the same behavior for malloc(0) - perror();abort;
in all cases.
"Erwin S. Andreasen" <erwin@ANDREASEN.COM> wrote
>malloc() etc. take a size_t argument, which is unsigned (and represents
>the result of a sizeof AFAIR).
This is what I thought too, but my test code was not behaving as
I thought it should. Turns out I was comparing the results of
malloc(-100) with malloc((unsigned int)-100). This results in
different behavior because size_t is unsigned _long_. D'oh!
Still, adding a check to CREATE/RECREATE to make sure the number
is reasonable (>0 for malloc, >=0 for realloc) _might_ be prudent,
particularly if care has not been taken in making sure all the
numbers passed to malloc/calloc are of type size_t. I know in my
add-on code, I have not done so. Half of the CREATE calls in base
Circle have a hard coded number, so the compiler can optimize away
the check anyway.
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST