On 13 December 2016 at 20:17, Austin English austinenglish@gmail.com wrote:
/* buf was originally [24], increased to 48 to prevent a stack smashing error when running tests under Valgrind */unsigned char buf[48]; /* "-1.1111111111111111E-308". */
The more interesting comment would perhaps be what actually happens and why this helps.
One thing I do notice is that while 24 chars would be enough to hold "-1.1111111111111111E-308", that doesn't leave any room for the \0 terminator, while the other cases above this one do seem to include space for that.
On Wed, 2016-12-14 at 10:20 +0100, Henri Verbeet wrote:
On 13 December 2016 at 20:17, Austin English austinenglish@gmail.com wrote:
/* buf was originally [24], increased to 48 to prevent a stack smashing error when running tests under Valgrind */unsigned char buf[48]; /* "-1.1111111111111111E-308". */The more interesting comment would perhaps be what actually happens and why this helps.
Valgrind doesn't really support 80-bit floating point arithmetic: http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits
One thing I do notice is that while 24 chars would be enough to hold "-1.1111111111111111E-308", that doesn't leave any room for the \0 terminator, while the other cases above this one do seem to include space for that.
The other cases need space for \0 because they use sprintf. Length is always passed so callers should not depend on zero-termination.
On 14 December 2016 at 11:02, Hans Leidekker hans@codeweavers.com wrote:
On Wed, 2016-12-14 at 10:20 +0100, Henri Verbeet wrote:
On 13 December 2016 at 20:17, Austin English austinenglish@gmail.com wrote:
/* buf was originally [24], increased to 48 to prevent a stack smashing error when running tests under Valgrind */unsigned char buf[48]; /* "-1.1111111111111111E-308". */The more interesting comment would perhaps be what actually happens and why this helps.
Valgrind doesn't really support 80-bit floating point arithmetic: http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits
That mentions limitations wrt. precision, rounding and fp exceptions, but from that page it's not obvious to me how that results in the mentioned stack corruption.
On Wed, 2016-12-14 at 11:18 +0100, Henri Verbeet wrote:
On 14 December 2016 at 11:02, Hans Leidekker hans@codeweavers.com wrote:
On Wed, 2016-12-14 at 10:20 +0100, Henri Verbeet wrote:
On 13 December 2016 at 20:17, Austin English austinenglish@gmail.com wrote:
/* buf was originally [24], increased to 48 to prevent a stack smashing error when running tests under Valgrind */unsigned char buf[48]; /* "-1.1111111111111111E-308". */The more interesting comment would perhaps be what actually happens and why this helps.
Valgrind doesn't really support 80-bit floating point arithmetic: http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits
That mentions limitations wrt. precision, rounding and fp exceptions, but from that page it's not obvious to me how that results in the mentioned stack corruption.
I didn't debug this (and I don't feel like it to be honest) but there are loops in the formatting code which terminate depending on the precision and rounding of long double operations. Valgrind can't match the precision of hardware because it uses 64-bit numbers internally to represent long doubles.
On 14 December 2016 at 11:34, Hans Leidekker hans@codeweavers.com wrote:
I didn't debug this (and I don't feel like it to be honest) but there
Ideally Austin would have, but fair enough.
are loops in the formatting code which terminate depending on the precision and rounding of long double operations. Valgrind can't match the precision of hardware because it uses 64-bit numbers internally to represent long doubles.
That makes some sense, although IIRC the FPU is by default in double precision mode as opposed to extended precision mode on Windows. (See also signal_init_thread() in ntdll.) Does that also imply a similar issue could happen if an application changed the FPU to single precision mode?
On Wed, 2016-12-14 at 11:50 +0100, Henri Verbeet wrote:
On 14 December 2016 at 11:34, Hans Leidekker hans@codeweavers.com wrote:
I didn't debug this (and I don't feel like it to be honest) but there
Ideally Austin would have, but fair enough.
are loops in the formatting code which terminate depending on the precision and rounding of long double operations. Valgrind can't match the precision of hardware because it uses 64-bit numbers internally to represent long doubles.
That makes some sense, although IIRC the FPU is by default in double precision mode as opposed to extended precision mode on Windows. (See also signal_init_thread() in ntdll.) Does that also imply a similar issue could happen if an application changed the FPU to single precision mode?
Yes. It would be interesting to see what webservices does on Windows in that case. We already set and restore the rounding mode.
-
Hans Leidekker -
Henri Verbeet