I'am a co-developer of SMLserver, which is a Standard ML interpreter
for AOLserver making it possible to script with Standard ML, see
http://www.smlserver.org.
Standard ML is a strict typed language, and we try to bring types into
most of the interfaces that we build. We are currently working on a
typed cache interface. It is then possible to create caches mapping
values of some domain type (e.g., integers) into some range type (e.g.,
pairs of strings). In order to obtain type safety we must append type
information to the cache name that the user provides, that is, our
cache names may be larger than the current limit of 32 characters (see
file /aolserver-3.5.1-src/nsd/cache.c in the source distribution line
64).
We have implemented the interface and to start with it seemed to work
perfect. However, when we tried with yet more complicated domain and
range types AOLserver started to fail completely, that is, dump core.
The reason is that the cache name began to be larger than 32
characters, and there is no mechanism in the cache API that prevents
this to happen (in particular the call to strcpy in function
CacheCreate line 1197).
My question is why the cache name is not dynamically allocated, so that
it can be arbitrary long. I can't see that there should be a efficiency
problem with a dynamically allocated cache name - however I may be
overlooking some details?
There's no specific reason for the 32byte limit and not checking for overflow is just a stupid oversight. AOLserver 4.0 has no limit as you suggest - the cache structure is grown to hold the required number of bytes in the string name. The 3.5 code could be patched to work the same way.
-Jim
