BUGS file

BUGS file

[Roland McGrath]

The BUGS file hasn't changed in going on two years.  I don't think we want
to have a file like this any more, we should just use bugzilla for
everything.  Are the items in here still relevant?  If so, we should file a
bugzilla report for each one.  Then let's nuke this file altogether.


Thanks,
Roland

Re: BUGS file

[Ulrich Drepper]

I've used mainly to decribe bugs which are known, and possibly big, and
which will not be fixed.  At least not anytime soon.  This is not
something we usually had in gnats.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

Re: BUGS file

[Roland McGrath]

> I've used mainly to decribe bugs which are known, and possibly big, and
> which will not be fixed.  At least not anytime soon.  This is not
> something we usually had in gnats.

I think these are fine things to have in bugzilla.  They can be left in
WONTFIX state for long periods if people don't want to see they come up in
the common queries.  

Re: BUGS file

[Ulrich Drepper]

Roland McGrath wrote:

> I think these are fine things to have in bugzilla.  They can be left in
> WONTFIX state for long periods if people don't want to see they come up in
> the common queries.  

But WONTFIX is closed and therefore usually doesn't show up in normal
queries.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

Re: BUGS file

[Roland McGrath]

> Roland McGrath wrote:
> 
> > I think these are fine things to have in bugzilla.  They can be left in
> > WONTFIX state for long periods if people don't want to see they come up in
> > the common queries.  
> 
> But WONTFIX is closed and therefore usually doesn't show up in normal
> queries.

Well, whatever.  I still think using bugzilla for these long-term items is
fine.  But at the very least, we need to clean stale items out of the BUGS
file.

Re: BUGS file

[Jakub Jelinek]

On Mon, Jun 28, 2004 at 04:34:25PM -0700, Roland McGrath wrote:
> Well, whatever.  I still think using bugzilla for these long-term items is
> fine.  But at the very least, we need to clean stale items out of the BUGS
> file.

And update the bugreporting instructions in there:

Another source of information about bugs is the problem data base of the
GNU project.  There is an easy to use WWW interface available at

       http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl

I would appreciate it very much if you could verify the problem was not
reported before by looking through the database.  To make the information
in this database as useful as possible please report bugs always using the
`glibcbug' shell script which gets installed with GNU libc.

	Jakub

Re: BUGS file

[Roland McGrath]

> And update the bugreporting instructions in there:

Yeah, http://sources.redhat.com/bugzilla/show_bug.cgi?id=234 is about this.
That's what motivated me to look at the file.  It all looks so stale that
rather than just update those instructions I thought about nuking the file.

Can we verify now which of these items still applies?

  [ **]  Closing shared objects in statically linked binaries most of the
	 times leads to crashes during the dlopen().  Hard to fix.

Don't know.

  [ **]  There are problems with signal handling when using LinuxThreads.

Not planning to fix this, since we have NPTL now.

  [ **]  The RPC code is not 64 bit clean.  This is getting slowly fixed
	 but expect incompatible changes on 64 bit platforms like Alpha.

I think this may now be as fixed as it's going to get.

  [ **]  If a DSO is using implicitly libpthread and the application itself
	 does not there is a name lookup problem.  E.g., the function fork()
	 will be found in the libc.so instead of libpthread since the thread
	 library is behind the libc.  To correct this problem it must *not*
	 be relied on the currently still enabled handling of weak symbols
	 in the dynamic linker.  Instead explicit tests for the availability
	 of the libpthread version are needed.  [PR libc/2325]

I don't think this is a problem any more, since those functions that are
duplicated between libc and libpthread now always forward to their counterpart.

  [  *]  The precision of the `sinhl' and/or `asinhl' function do not seem
	 to be the best.
  [  *]  The libm-ieee `gamma' function gives wrong results (at least for
	 -0.5).
  [  *]  The libm-ieee `scalb' function gives wrong results for
	 non-integral second parameters.

I don't know the status of these, though libm has had various changes in
the last two years since BUGS was updated.

  [  *]  On Linux, there should be a way to prevent defining the symbol
	 NGROUPS_MAX in the <linux/limits.h> header file.  In glibc it
	 is defined in <posix1_lim.h> which must not make the other
	 symbols in <linux/limits.h> available.
	 [PR libc/140]

This is still the case.  But it's really something that needs to be changed
in the installed <linux/limits.h> kernel header, and then libc will do the
right thing.

  [  *]  Several (most?) collation specifications are broken.  

I don't know anything about this stuff.

  [  *]  Some of the functions which also handled IPv6 are currently broken.
	 IPv6 and IPv4 lookups occasionally happen when not needed.  This
	 happens in getaddrinfo() and getnameinfo().  IPv4 handling of
	 these functions is OK though and there are patches available to fix
	 the IPv6 code as well.

I believe this is fixed now.  If anything remains to do here, it should
have an active bugzilla report since it's something we don't want to have
slide forever.


Thanks,
Roland