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