Re: fcvt safety
SteveB wrote:
I've come across a document that doesn't list doubles as a supported
datatype on the premise that functions to manipulate them use
'statically allocated buffers'.
That statement as it stands is nonsense.
This comes after we have used fcvt within out code to add support for
doubles etc.
fcvt() OTOH does use a static buffer, thus needs thread-local storage and
careful use in order to be safe. A websearch turns up lots of hits that
also flag this as dangerous/obsolete.
When I read the info about fcvt using a statically allocated buffer for
subsequent calls I assumed that this meant calls to this function
within the same object. The object in question is a single threaded com
object.
Hmmm, I'm not sure. I know that different processes will have separate
buffers for fcvt() while different threads in the same process will share
the buffer unless it was explicitly made thread-local storage.
The function itself would be called by more than one class (2)
and i'm working on the assumption that these two objects won't be
created at the same time (the code creates them sequentially, could the
execution create them as it sees fit ?).
Normally classes don't call things, rather instances of classes. Also, what
language are we talking about? And where/how do they call this? C++'s
deterministic cleanup might assure there is no concurrent access, C#'s
garbage collection might ruin that. Also, what about other libs/modules you
might not even know of that access fcvt()?
I'd suggest using sprintf() until you know that you need something
fcvt-like. And in that case, you could also create a similar function that
takes a buffer as parameter, like fcvt_r.
Uli