>Heh heh... and none of them have this declaration from DateTime.c:
>
> // Max length of any date template string (before expansion), with the null.
> #define maxDateTemplateLen 32
>
>which is the maximum size of the conversion buffer, and thus the maximum
>size of the resulting string, including the zero byte C-string terminator.
No, that's not the max size of the resulting string; it is the size of the
template buffer. (That's why it says "template" in the definition :-) The
template is the definition of what order things should be in the resulting
string. The resultant string is a different buffer.
New code in the 3.5 DateToDOWDMFormat includes the following to determine
the max size of the resulting string:
if (((UInt16)dateFormat >= dfMDYLongWithComma) && ((UInt16)dateFormat <=
dfYMDLongWithSpace))
maxLen = dowLongDateStrLength;
else
maxLen = dowDateStringLength;
... and those are defined in the 3.5 version of DateTime.h:
#define dowDateStringLength 19
#define dowLongDateStrLength 25
I agree that it appears that we now require a larger buffer than was
specified during 2.0 and 3.0. Looks like a mess-up on our part.
The old contents of DateToAscii is horrible, and it'd be quite a task to
figure out how long its maximum would be. No wonder we scrapped it and
rewrote it in the DateTemplateToAscii style.
>what concerns me is that this does not consistently cause problems with the
>Debug ROM, so it's not just a matter of the Debug ROM over-aggressively
>filling memory to flush out errors (if that were true, it should be 100%
>consistent).
The debug rom does indeed clear out 'maxLen' bytes of the buffer with 0xfe.
So I'm not sure what that means, but it is interesting that you don't get
consistent failures.
-David Fedor
Palm Developer Support
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
