> I've used it to the extreme (to revenge?) by creating a
 > dynamic array and realloc() everytime the size of the array
 > is incremented. The compiler and the library happened to be
 > Microsoft C6.?.
 
 dn> I'm not sure that the analysis is particularly fair or accurate. I've
 dn> used C6's (to be precise, 6.0A) realloc() extensively and have never
 dn> hit the same problem, and some of the software in which it is used has

I was in a terrible mood after having been forced to spend an hour on a
"quick hack" task because of the bug. I tried to reproduce the
error after reading your message but couldn't. The code had been modified
to fix other bugs elsewhere. Seems like one of these bugs inadvertently
changed the code in realloc() and made it look like MSC6 realloc()'s fault.
Thanks for your clarification and apology to all.

 dn> Could this be yet another case of the "scanf() syndrome"?  :-)

Maybe. Maybe not. realloc() is not as powerful and difficult to master as
scanf(). It's just one of the functions I dislike because of personal
reasons:

realloc() -> memory fragmentation -> inefficient use of heap =>
why not design a better algo for the program?

strtok() -> change the string, defined inconsistent behaviour, some
compilers use non re-entrant code => use with care

strncat() -> inconsistent naming convention

BTW, scanf() is one of my favourite functions.


--- GEcho 1.01+