Thread

1. Re: [HACKERS] Patch for glibc2 date problems

   Oliver Elphick <olly@lfix.co.uk> — 1998-01-16T06:42:44Z

   "Thomas G. Lockhart" wrote:
     >> The patch for glibc2 dates is attached.  With this applied, a Linux system
     >> with libc6 (glibc2) passes all the date and time related regression tests.
     >
     >It looks as though this patch is a bit Linux-specific (or specific to some v
         >ersion of glibc which has only been tested on
     >Linux).
   
   I don't have experience of using glibc2 on any other type of machine.
   
   However, isn't part of the point of it to remove inter-machine differences?
   
     >
     >Can we wait until glibc2 settles down, or provide this as an add-on patch ra
         >ther than merging it into the main tree? I hate
     >adding machine-specific code into otherwise general code...
   
   I guess that's up to you.  
     >
     >Another possibility would be to add a new #define variable like HAVE_FUNNY_L
         >IBRARY in config.h or in linux.h so we can
   
   Why isn't
    #if __GLIBC__ < 2
   enough for this?
     >possibly use this with other ports if necessary in the future.
     >
   
   I don't have experience of using glibc2 on any other type of machine.
   However, isn't part of the point of it to remove inter-machine differences?
   
     >I'm planning on installing RH5.0 sometime soon (I have a clean disk so can f
         >all back to RH4.2). I'm sure I'll sound more
     >sympathetic by then  :)
     >
     >                                                    - Tom
   
   My assumption was that any system using glibc2 would not have a broken 
   rint() function; so the general change to TMODULO would be justified.
   
   The change of the test of `var != 0' to `var != rint(var)' should not break
   anything, even if var is non-zero.  It is merely saying, don't use
   decimal points if there's no decimal part.
   
   The remaining part of the patch is to force the undefinition of
   HAVE_INT_TIMEZONE; again this is glibc2-specific, but I don't know
   any reason to suppose it wouldn't be needed on any machine with glibc2.
   
   It would really be helpful to have someone on a non-Linux machine test
   it; but is there anyone?
   
   
   -- 
   Oliver Elphick                                Oliver.Elphick@lfix.co.uk
   Isle of Wight                              http://www.lfix.co.uk/oliver
   
   PGP key from public servers; key ID 32B8FAA1
   
   Unsolicited email advertisements are not welcome; any person sending
   such will be invoiced for telephone time used in downloading together
   with a £25 administration charge.
   
   
   
   

2. Re: [HACKERS] Patch for glibc2 date problems

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-16T14:17:47Z

   > 
   > "Thomas G. Lockhart" wrote:
   >   >> The patch for glibc2 dates is attached.  With this applied, a Linux system
   >   >> with libc6 (glibc2) passes all the date and time related regression tests.
   >   >
   >   >It looks as though this patch is a bit Linux-specific (or specific to some v
   >       >ersion of glibc which has only been tested on
   >   >Linux).
   > 
   > I don't have experience of using glibc2 on any other type of machine.
   > 
   > However, isn't part of the point of it to remove inter-machine differences?
   > 
   >   >
   >   >Can we wait until glibc2 settles down, or provide this as an add-on patch ra
   >       >ther than merging it into the main tree? I hate
   >   >adding machine-specific code into otherwise general code...
   > 
   > I guess that's up to you.  
   >   >
   >   >Another possibility would be to add a new #define variable like HAVE_FUNNY_L
   >       >IBRARY in config.h or in linux.h so we can
   > 
   > Why isn't
   >  #if __GLIBC__ < 2
   > enough for this?
   >   >possibly use this with other ports if necessary in the future.
   >   >
   > 
   > I don't have experience of using glibc2 on any other type of machine.
   > However, isn't part of the point of it to remove inter-machine differences?
   > 
   >   >I'm planning on installing RH5.0 sometime soon (I have a clean disk so can f
   >       >all back to RH4.2). I'm sure I'll sound more
   >   >sympathetic by then  :)
   >   >
   >   >                                                    - Tom
   > 
   > My assumption was that any system using glibc2 would not have a broken 
   > rint() function; so the general change to TMODULO would be justified.
   > 
   > The change of the test of `var != 0' to `var != rint(var)' should not break
   > anything, even if var is non-zero.  It is merely saying, don't use
   > decimal points if there's no decimal part.
   > 
   > The remaining part of the patch is to force the undefinition of
   > HAVE_INT_TIMEZONE; again this is glibc2-specific, but I don't know
   > any reason to suppose it wouldn't be needed on any machine with glibc2.
   > 
   > It would really be helpful to have someone on a non-Linux machine test
   > it; but is there anyone?
   
   Our code is complicated enough without adding patches for OS bugs.  A
   good place for the patch is the Linux FAQ.  If it really becomes a
   problem, we can put the patch as a separate file in the distribution,
   and mention it in the INSTALL instructions.  If you really want to get
   fancy, as I did with the flex bug, you can run a test at compile time to
   see if the bug exists.
   
   -- 
   Bruce Momjian
   maillist@candle.pha.pa.us