In article <84ttlr$4lk$1 at niobium.hgmp.mrc.ac.uk>,
Alan Bleasby <ableasby at hgmp.mrc.ac.uk> wrote:
>In reply to James/Tim:
>>Yes, but its hard to see why strftime was overlooked
>nonetheless.
Probably because any routine calling strftime() has to manage the buffer
into which the formatted string is placed, whereas SRS' TimeToString has
a group of static buffers used cyclically. I'm not sure whether this is
good or bad; it reduces the likelihood of memory allocation bugs, but
raises the possibility of much more subtle bugs; your results from
TimeToString will be overwritten on the 10th call to TimeToString. It
might not be easy to predict when this will happen, so if you want a
permanent copy of the output of TimeToString, you need to strdup it
anyway, or strcpy it to another buffer.
It can't be because of portability issues, since TimeToString itself
already uses time.h.
Overall I agree, strftime would have been a better choice.
Mind you, there's lots about the SRS sources I find perplexing. Why,
for example, do so many routines, including TimeToString, take
parameters which are null terminated strings, of which only the first
character is actually used, to supply option flags?
I imagine Thure (or whoever wrote the code originally) did this to make
the code more readable, but surely this is what #define constants are
for? The single character system that's currently being used limits the
routine to only one option at a time, and a rather limited number of
options at that...
Tim.
