Re: [HACKERS] Patch for glibc2 date problems

>
> "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