Re: [xml] core dump - yes its real and needs a fix.

[Bjorn Reese <breese mail1 stofanet dk>]

stan boehm philips com wrote:

> The problem is that there is not enough stack on my system to support
> creating the following buffer in the function TrioWriteNumber().
[...]
>   char buffer[MAX_CHARS_IN(LONGEST)
>              * MAX_LOCALE_SEPARATOR_LENGTH
>              * MAX_LOCALE_GROUPS];

Yes, this could very well be the problem. The size of this buffer is
meant to be the largest possible size that can be used. However, I just
notice that the last part (MAX_LOCALE_GROUPS) is completely unnecessary.
You can remove it from both TrioWriteNumber and TrioWriteDouble.

> In the meantime, I would like to know if it is really necessary for
> a hard realtime system to support 64 locale groups and if the
> MAX_LOCALE_SEPARATOR_LENGTH could not also be reduced.
> Perhaps as a function of the OS, more #ifdefs YUK ???

Yes, I believe that it can be reduced. Although the thousand separator
is defined as a string, it will normally will be a single character at
most -- though, it can be a multi-byte character. The QNX man page for
localeconv() explictly calls the thousand separator "the character used
to separate groups" (note the wording 'the character'), so I would guess
that you can lower it to, say, 16 -- this should also allow for plenty of
room for an odd multi-byte character encoding.

Thanks for the excellent debugging work.