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

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_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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]