← Back to team overview

maria-developers team mailing list archive

Re: MariaDB test question (main.cast)


Hi, sje!

On Oct 24, sje@xxxxxxxxxx wrote:
> I have downloaded, built and tested MariaDB 5.3.2 Beta on HP-UX 11.31
> and I get two test failures, I have a question about one of tests that
> I was hoping someone could help me with.
> The main.cast test fails and the problem is with this part of the test:
> select cast(cast(20010203101112.1 as double) as datetime(1));
> It is converting the string "20010203101112.1" to a double value and then
> converting the double value to a date.  The test expects "2001-02-03
> 10:11:12.1" to be output but I am getting  "2001-02-03 10:11:12.0".
> I think the problem is with the conversion into floating point.  When I
> use gdb to break sql at double_to_datetime, on HP-UX the value I have is
> 20010203101112.098, on Linux I see 20010203101112.102.  Neither value
> is completely correct because 20010203101112.1 cannot be represented
> exactly as an IEEE floating point value.

Thanks. Good analysys!

> So I have two questions.  Where did the string get converted into a
> floating point value?  I couldn't find where this is happening, I assume
> it is using strtod or something but breaking on that function didn't
> do anything.  Secondly, given that 20010203101112.1 cannot be represented
> exactly as a double precision floating point value, is this a valid test?

Two answers:
There should be no strtod, because the argument of the cast(... as double)
is not a string, but a decimal number. I'd expect the conversion to
happen in decimal2double() function.
Secondly, I think you're right - it is not.

> FYI: The other failure I get is main.cast, this test is trying to check
> for a stack overflow before it happens but IA64 HP-UX  has two stacks, a
> register stack and a user data stack.  In this test case the recursion of
> p_ere and p_ere_exp wind up using only the register stack because all the
> local variables and arguments are  stored in registers.  The stack check
> in check_stack_overrun is checking the user stack which doesn't overflow
> (or even change) and so we eventually die with a register stack overflow.
> There is a way to check the register stack on IA64 HP-UX, but it would
> require using IA64 assembly language so it may not be worth doing.

Okay. What would you suggest? Just disable the test in the test suite?
Do not check for stack overflow on IA64 HP-UX at all?
Check for both stacks?


Follow ups