This is the mail archive of the
mailing list for the glibc project.
Re: glibc conditioning
- To: Jinsong Zhao <zhaojs at cadence dot com>
- Subject: Re: glibc conditioning
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Mon, 27 Aug 2001 15:52:03 -0700 (PDT)
- cc: <libc-alpha at sources dot redhat dot com>
On Mon, 27 Aug 2001, Jinsong Zhao wrote:
> is the most relevant. In my case, in gdb I can see that two variables
> a and b, both double, are the same up to 16 digits, yet if(a==b) fails
> on Linux while on Solaris (compiled under gcc) it succeeds. Then I
You can't compare floating point quantities for exact equality
the same way as integers.
Your engineers should the well-known paper ``What Every Computer
Scientist Should Know About Floating Point'' and fix the program
> would have different sorted order of some data structure. Then it's no
> surprise the results are different. The problem is that we use a lot
> of legacy codes and debugging those codes is extremely difficult.
So you are saying that a system library used by many applications,
and running on millions of desktops and servers should be changed to
fix a buggy application that is composed of legacy code that even
its current maintainers don't want to touch?
There is something wrong with the *form* of this proposition, regardless
of the specific technical issues involved.
> obstacle for us to make the transition to Linux. Worse yet, this time
> the resistance is not from management, the resistance will come from
> engineers. Fixing these types of problems is exactly the support we
The people working on the platform itself are also engineers, and you
will find that they will also resist. So you will have to just
push the work onto a group of engineers who don't resist. :)
> expect to get from the vendor of any platform which we support.
Given that the library is maintained by volunteers in their spare time,
your suggestion that you are entitled to some kind of support appears
arrogant (even if it's not intended that way---that's e-mail for you).
But name one proprietary vendor who will change a library just for you,
without requiring a pile of money upfront to cover all the development
costs. E.g. if it takes one assigned developer three months, and that
developer makes $100,000 per year, then it will cost at least $25,000.
The license that accompanies the GNU C library tells you that you are not
entitled to any such free support: the software comes with no warranty.
(And note that in this regard, it does not differ from most proprietary
licenses!) If you want something special developed just to fix an issue
you are having, you will have to pay, or otherwise motivate, someone to
do the development. You have the source code, so you can assign the work
to absolutely anyone who you feel is qualified (with the understanding
that if you distribute the resulting modified library, you will have to
distribute the source code as well).
The results of that special work may quite possibly be rejected from
being part of the mainstream library, so your application will have to
live with a forked library for the rest of its lifecycle.
It may be better just to spend the money on fixing the application to
make its numerical code properly portable. Then you won't have to go
through the same problems all over again with yet another library or
compiler on yet another platform.