[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[ams at gnu dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823

--- Comment #4 from Alfred M. Szmidt  ---
   > Created attachment 9857 [details]
   > Don't use arbitrary limits.
   > 
   > The following fixes fixincludes.
   > 
   > fixincludes/ChangeLog
   > 2005-09-16  Alfred M. Szmidt  
   > 
   >* fixincl.c (quoted_file_exists): Use xmalloc to allocate memory
   >for FNAME.
   >(create_file): Use xmalloc to allocate memory for FNAME.
   > 
   >* server.c (server_setup): Use dynamic allocation for BUFF.

   Please send this patch to the gcc-patches mailing list for review, if it
still
   applies

MAXPATHLEN is still used in fixincludes.  Seeing that this patch is
over 10 years, I am not sure it even applies and thus a good idea to
forward it to gcc-patches for review.  The fix is simple enough in
fixincludes (simply use xmalloc).

[Bug target/28102] [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

[ams at gnu dot org]

--- Comment #21 from ams at gnu dot org  2007-10-01 18:04 ---
Subject: Re:  [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared

   To me it looks like linux.h shouldn't be included

It should be included.

   and gnu.h should be made uclibc-aware..

This would be nice, would you like to do that?  I have far to much to
handle right now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

[ams at gnu dot org]

--- Comment #18 from ams at gnu dot org  2006-08-24 18:05 ---
Subject: Re:  [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared

I'll try to get around it as soon as I can.  Thanks.

   It has been a month... would be nice if you could look at it soon.

Thanks for poking, I got stuck on a strange bug that causes make to
assert while building the Java bits and I haven't gotten around to
fixing it.  I'll try and get around to atleast fixing this bug ASAP;
which may take some time. :( Is there a hurry getting this in, I could
try and reprioritise my tasks if it is urgent.

Happy hacking, and thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

[ams at gnu dot org]

--- Comment #16 from ams at gnu dot org  2006-07-26 15:35 ---
Subject: Re:  [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared

I'll try to get around it as soon as I can.  Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

[ams at gnu dot org]

--- Comment #2 from ams at gnu dot org  2006-07-15 13:45 ---
Created an attachment (id=11892)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11892action=view)
Fixes #28102

(In reply to comment #1)
 Why is GNU target including linux.h header at all?
 TARGET_C99_FUNCTIONS should be overridden in gnu.h anyways.

Because the rules in config.gcc say so:

*-*-gnu*)
...
i[34567]86-*-*)
  tm_file=${cpu_type}/${cpu_type}.h i386/unix.h i386/att.h dbxelf.h
elfos.\
h svr4.h linux.h i386/linux.h gnu.h ${tm_file}
...


Here is a patch that fixes the problem.

gcc/ChangeLog
2006-07-15  Alfred M. Szmidt  [EMAIL PROTECTED]

   * config/i386/gnu.h (TARGET_C99_FUNCTIONS): Undefine macro.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

[ams at gnu dot org]

--- Comment #4 from ams at gnu dot org  2006-07-15 15:17 ---
Subject: Re:  [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared

Because the rules in config.gcc say so:

   And that is not why, but that is what is causing linux.h being
   included?  Again why is Linux.h being included?

GNU and GNU/Linux are similar enough not to warrant duplication of the
code from linux.h in gnu.h.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

[ams at gnu dot org]

--- Comment #6 from ams at gnu dot org  2006-07-15 15:45 ---
Subject: Re:  [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared

   Only the following code will be duplicated which is hardly any
   after all:

That is from [gcc]/gcc/config/linux.h, I'm talking about
[gcc]/gcc/config/i386/{linux,gnu}.h.  Which is also the one causing
problems without the patch I sent.

I don't want/have time/etc to worry about this right now, it isn't a
very high priority thing anyway.  I also don't think it is a very good
idea to copy the content form */linux.h into */gnu.h...

FYI, GNU/k*BSD also uses the GNU/Linux headers, and it doesn't support
uclibc AFAIK.

Cheers.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

[ams at gnu dot org]

--- Comment #8 from ams at gnu dot org  2006-07-15 16:07 ---
Subject: Re:  [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared

Can you please just apply the patch and close the bug?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

[ams at gnu dot org]

--- Comment #11 from ams at gnu dot org  2006-07-15 16:25 ---
Subject: Re:  [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared

Can you please just apply the patch and close the bug?

   Why it is not obvious and I say the patch is incorrect.

The patch is correct, that you think that the code we use from
*/linux.h should be in */gnu.h is not related to this bug.  This is
the setup we have used for almost 10 years, and I see no reason to
change it.  The setup works, it minimises the workload on both
parties, and it is clean.

If you don't want to commit the patch then that is fine, it isn't like
GCC can even compile on the GNU system due to the other bugs with
patches being neglected (mostly by me).

Happy hacking.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

[ams at gnu dot org]

--- Comment #12 from ams at gnu dot org  2006-07-15 16:27 ---
Subject: Re:  [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared

   Oh did I forget (again) to say you really should be posting patches
   to the gcc-patches mailing list.

Thanks.  I'm actually quite aware of that.  I haven't gotten around to
cleaning it all up so that I can send it to gcc-patches@ in one go.

   Also the comment in your patch is incorrect as the definition comes
   from config/linux.h and not from config/i386/linux.h.

Thanks.  I confused it with config/alpha/linux which defines
TARGET_C99_FUNCTIONS.

Cheers.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102

[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared

[ams at gnu dot org]

--- Comment #14 from ams at gnu dot org  2006-07-15 16:55 ---
Subject: Re:  [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared

I think we will have to agree to disagree on this, since neither you
or I will change our minds. :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102

[Bug ada/23187] MAXPATHLEN usage in gcc/ada/*.c

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-10-01 16:46 ---
You also have access to a GNU system, GNU/Linux.  It is easily testable there. 
Could you revert the fix?  It is better that fails loudly than having a
arbitrary limit.

I'll see about submiting a proper patch.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23187

[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-10-01 16:58 ---
Could someone go over these bugs and commit the pending patches?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824

[Bug ada/23187] MAXPATHLEN usage in gcc/ada/*.c

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-08-31 14:56 ---
Subject: Re:  MAXPATHLEN usage in gcc/ada/*.c

This patch is a kludge, GNU does not have any limit what-so-ever on
the length of a filename.  And it is a horrible kludge, since it is
common to have filenames longer than 256 chars.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23187

[Bug ada/23187] MAXPATHLEN usage in gcc/ada/*.c

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-08-31 15:00 ---
Subject: Re:  MAXPATHLEN usage in gcc/ada/*.c

   --- Additional Comments From charlet at gcc dot gnu dot org  2005-08-29 
13:14 ---
   Should not cause compilation error any more.

The fix is wrong, GNU doesn't have any limit on the length of
filenames.  Defining a atribitary limit is not a fix.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23187

[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-08-09 17:45 ---
Subject:  i*86-*-gnu* not enabled in configure.ac

The following fixes #21819 (I was requested to send it to gcc-patches@
and java-patches by Andrew Pinski).

2005-08-09  Alfred M. Szmidt  [EMAIL PROTECTED]

* configure.ac: Detect the GNU system.

--- libffi/configure.ac
+++ libffi/configure.ac
@@ -41,6 +41,7 @@
 
 TARGETDIR=unknown
 case $host in
 i*86-*-linux*) TARGET=X86; TARGETDIR=x86;;
+i*86-*-gnu*) TARGET=X86; TARGETDIR=x86;;
 i*86-*-solaris*) TARGET=X86; TARGETDIR=x86;;
 i*86-*-beos*) TARGET=X86; TARGETDIR=x86;;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819

[Bug fortran/23065] MAXPATHLEN usage in fortran/{scanner,module}.c

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-08-01 17:48 ---
Subject: Re:  MAXPATHLEN usage in fortran/{scanner,module}.c

   So, does GNU define _POSIX_PATH_MAX?

No.

   Does GNU support pathconf()?

Yes.

   I read the other thread where it is suggested that a non-portable
   GNU extension should be used.  The gfortran source is fairly clean
   from such kludges, and I would oppose the introduction of one.

In this case using getcwd(NULL, 0) (and it is easy to make this
portable), isn't neeed.  But there is nothing kludgy about GNU
programs using GNU extentions.

In either case, I have a patch in the brew that should fix all
MAXPATHLEN/PATH_MAX issues in the whole GCC tree, which I will post as
soon as I have tested it (should be in few days).

Happy hacking.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23065

[Bug fortran/23065] MAXPATHLEN usage in fortran/{scanner,module}.c

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-08-01 18:24 ---
Subject: Re:  MAXPATHLEN usage in fortran/{scanner,module}.c

   So, does GNU define _POSIX_PATH_MAX?

No.

   Then GNU isn't POSIX compliant.

Sorry, I meant yes.  We do define _POSIX_PATH_MAX.  My brain failed to
communicate this to my fingers.

(As for GNU being POSIX compliant, we are POSIX compliant where it
makes sense)


   Does GNU support pathconf()?

Yes.

   Use pathconf instead of ...


   I read the other thread where it is suggested that a non-portable
   GNU extension should be used.  The gfortran source is fairly clean
   from such kludges, and I would oppose the introduction of one.

In this case using getcwd(NULL, 0) (and it is easy to make this
portable), isn't neeed.  But there is nothing kludgy about GNU
programs using GNU extentions.

   this ugly hack.

This isn't a ugly hack.  GNU programs should use GNU extentions where
possible.

   Don't bother with gfortran.  I've regression testing a patch that
   uses alloca as suggested by Andrew.

Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23065

[Bug libffi/21819] New: i*86-*-gnu* not enabled in configure.ac

[ams at gnu dot org]

i*86-*-gnu* not enabled in configure.ac, which makes configure fail if you try
to compile libffii on GNU.

-- 
   Summary: i*86-*-gnu* not enabled in configure.ac
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libffi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819

[Bug java/21821] New: MAXPATHLEN usage in [gcc]/libjava/gnu/java/nio/channels/natFileChannelImpl.cc

[ams at gnu dot org]

Please do not use MAXPATHLEN, it is a arbitrary limit, and is not
defined on GNU.  Currently this makes libjava (gcc 4.0.0) unbuildable on GNU
since [gcc]/libjava/gnu/java/nio/channels/natFileChannelImpl.cc assumes that
MAXPATHLEN is defined.  Please do not use these kind of limits in GNU programs.

Not having MAXPATHLEN is perfectly compliant with POSIX, same goes for
MAXHOSTNAMELEN, PATH_MAX etc.

-- 
   Summary: MAXPATHLEN usage in
[gcc]/libjava/gnu/java/nio/channels/natFileChannelImpl.c
c
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-05-30 14:42 ---
Created an attachment (id=8995)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8995action=view)
Add i*86-*-gnu* to configure.ac

Add GNU to the list of detected systems.

2005-05-30  Alfred M. Szmidt  [EMAIL PROTECTED]

* configure.ac: Detect the GNU system.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-05-30 14:53 ---
[gcc]/libjava/java/io/natFilePosix.cc is also broken due to the usage of 
MAXPATHLEN.

-- 
   What|Removed |Added

Summary|MAXPATHLEN usage in |MAXPATHLEN usage in libjava
   |natFileChannelPosix.cc  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-05-30 14:55 ---
Will do.  Thanks.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819

[Bug java/21822] New: fastjar/jartool.c's usage of MAXPATHLEN

[ams at gnu dot org]

The way MAXPATHLEN is used in jartool.c is wrong, instead of defining a bogus
value on platforms that do not have MAXPATHLEN defined (i.e. GNU) one should try
and use getcwd as follows:

  char *dir = getcwd (NULL, 0);

instead of passing a buffer and a size.

This will only work on systems that use the GNU C Library.

-- 
   Summary: fastjar/jartool.c's usage of MAXPATHLEN
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21822

[Bug c/21823] New: MAXPATHLEN usage in [gcc]/fixincludes

[ams at gnu dot org]

The way MAXPATHLEN is used in fixincludes (server.c and fixincl.c) is wrong,
instead of defining a bogus value on platforms that do not have MAXPATHLEN
defined (i.e. GNU) one should try and use getcwd as follows:

  char *dir = getcwd (NULL, 0);

instead of passing a buffer and a size.

This will only work on systems that use the GNU C Library.

-- 
   Summary: MAXPATHLEN usage in [gcc]/fixincludes
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-05-30 16:23 ---
(In reply to comment #2)
 Its easy to fix this for natFileChannelImpl.cc.

Thank you for fixing it!

 For natFilePosix.cc it is not so simple - is there a portable alternative to
 realpath() that does not require the use of MAXPATHLEN / PATH_MAX ?

One can call realpath() with NULL for the second parameter on systems that do
not have MAXPATHLEN/PATH_MAX.  You could also use canonicalize_file_name(), but
this is a GNU C library specific function.

 -- Function: char * realpath (const char *restrict NAME, char
  *restrict RESOLVED)
...
 On systems which define `PATH_MAX'
 this means the buffer must be large enough for a pathname of this
 size.  For systems without limitations on the pathname length the
 requirement cannot be met and programs should not call `realpath'
 with anything but `NULL' for the second parameter.

 -- Function: char * canonicalize_file_name (const char *NAME)
 The `canonicalize_file_name' function returns the absolute name of
 the file named by NAME which contains no `.', `..' components nor
 any repeated path separators (`/') or symlinks.  The result is
 passed back as the return value of the function in a block of
 memory allocated with `malloc'.  If the result is not used anymore
 the memory should be freed with a call to `free'.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug middle-end/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-05-26 12:59 ---
(In reply to comment #3)
 Like most POSIX limits PATH_MAX may not be defined if the actual limit is not 
  
 fixed.  

Correct, and GNU doesn't have such a limit for the length of filenames, the
number of arguments passed to a program or the length of a hostname.  And
probobly a whole bunch of other things that have slipped my mind right now.
All of this is perfectly compliant with POSIX.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21706

[Bug libmudflap/21724] New: [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir

[ams at gnu dot org]

When doing something like:

  make install includedir=/foo/bar/baz

in gcc 4.0.0 you get the following error:

test -z /include || mkdir -p -- /include
 /usr/bin/install -c -m 644
'/home/ams/gsc/devel/gcc/src/libmudflap/mf-runtime.h' '/include/mf-runtime.h'
/usr/bin/install: cannot create regular file `/include/mf-runtime.h': Permission
denied
make[5]: *** [install-includeHEADERS] Error 1

This applys to any platform, not just GNU.

Happy hacking.

-- 
   Summary: [gcc]/libmudflap/Makefile.am, refusing to install mf-
runtime.h in includedir
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724

[Bug libmudflap/21724] [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-05-23 17:28 ---
Created an attachment (id=8955)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8955action=view)
Fix for bug 21724

The following patch fixes the bug.

libmudflap/ChangeLog
2005-05-23  Alfred M. Szmidt  [EMAIL PROTECTED]

* Makefile.am (AM_MAKEFLAGS): Pass includedir.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724

[Bug c/21706] New: MAXPATHLEN usage in [gcc]/gcc/tlink.c

[ams at gnu dot org]

Please do not use MAXPATHLEN, it is a arbitrary limit, and is not
defined on GNU.  Currently gcc 4.0.0 is unbuildable on GNU since
[gcc]/gcc/tlink.c assumes that MAXPATHLEN is defined.  Please do not
use these kind of limits in GNU programs.

Suggested fix is to declare initial_cwd as:

  char *initial_cwd;

and then instead of doing:

  getcwd (initial_cwd, sizeof (initial_cwd));

do:

  initial_cwd = getcwd (NULL, 0);

Note: getcwd (NULL, 0) is a GNU extention, and might not be available
on non-GNU platforms.  (End of Note)

Sorry for not supplying a patch, happy hacking.

-- 
   Summary: MAXPATHLEN usage in [gcc]/gcc/tlink.c
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P1
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21706