Thread

  1. Status of glibc2 problems

    Oliver Elphick <olly@lfix.co.uk> — 1998-02-19T08:02:35Z

    Dates & times:
    I confirm that libc6 2.0.7pre1 cures all the time and date problems
    that I was having with glibc2.  So no patches are needed; just undefine
    HAVE_INT_TIMEZONE for glibc2.
    
    Int2, int4, oidint2, oidint4:
    In the regression tests, for glibc2 we should expect to see 'Numerical
    result out of range' rather than `Math result not representable'.
    
    New with libc6 2.0.7:
    Float4: some of the tests failed because glibc2 works _better_ than libc5!
    One test involves inserting values of 10e-40.  libc5 fails, but glibc2
    says that 10e-40 is equivalent to 1e-39 and successfully inserts it.
    It also stores larger numbers as Inf and -Inf and inserts these values rather
    than failing. So many of the tests report 9 rows instead of 5.
    
    Float8:
    Again some tests work which didn't with libc5:
    expected:
    QUERY: UPDATE FLOAT8_TBL  
       SET f1 = FLOAT8_TBL.f1 * '-1'
       WHERE FLOAT8_TBL.f1 > '0.0';
    QUERY: SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
    ERROR:  Bad float8 input format -- overflow
    
    glibc2:
    QUERY: SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
    bad|?column? 
    ---+----------------
       |0
       |-3.484e+201
       |-1.0043e+203 
       |Infinity 
       |-1.2345678901234
    (5 rows)
    
    On the other hand, this no longer works:
    expected:
    QUERY: SELECT '' AS bad, : (f.f1) from FLOAT8_TBL f;
    bad|            ?column?
    ---+--------------------
       |                   1
       |7.39912306090513e-16
       |                   0 
       |                   0 
       |                   1
    (5 rows) 
    
    glibc2:
    QUERY: SELECT '' AS bad, : (f.f1) from FLOAT8_TBL f;
    ERROR:  exp() result is out of range
    
    
    
    geometry:
    results from converting circles to polygons are still different by about
    3e-12 on some co-ordinates.
    
    triggers:
    I think the expected results are wrong:
     I get (among other differences): 
    QUERY: insert into fkeys2 values (70, '5', 3);
    ERROR:  check_fkeys2_pkey_exist: tuple references non-existing key in pkeys
    
    which is not in the expected results but looks right.
    
    
    select-views:
    many differences, but I believe these are also seen on other platforms.
    
    
    -- 
    Oliver Elphick                                Oliver.Elphick@lfix.co.uk
    Isle of Wight                              http://www.lfix.co.uk/oliver
    
    PGP key from public servers; key ID 32B8FAA1