Bugs in the Debian/GNU GNU compiler setup
		=========================================

Before reporting a bug, please
------------------------------

- Check that the behaviour really is a bug. Have a look into some
  ANSI standards document.
- Check at the end of this document for known bugs/behaviour.
- Check http://www.debian.org/Bugs, if this behaviour / this bug already
  is reported.
- Check http://gcc.gnu.org/bugs.html for known bugs.

When reporting a bug, please
----------------------------

- read /usr/share/doc/debian/bug-reporting.txt
- read http://gcc.gnu.org/faq.html#bugreport.
- included the PREPROCESSED output (foo.i or foo.ii) in your report.
- decide where to report the bug. Please send a CC to gcc@packages.debian.org,
  if you decide to report the bug directly to gcc-bugs@gcc.gnu.org.

How to report a bug
-------------------

[Taken from http://gcc.gnu.org/faq.html#bugreport]

There are complete instructions in the gcc info manual, section Bugs.
The manual can also be read using `M-x info' in Emacs, or if the GNU info
program is installed on your system by `info --node "(gcc)Bugs"'. Or see
the file BUGS included with the gcc source code.

Before you report a bug for the C++ compiler, please check the list of
well-known bugs. If you want to report a bug with an earlier version, we
recommend upgrading to the current release first.

In short, if gcc says Internal compiler error (or any other error that
you'd like us to be able to reproduce, for that matter), please mail a bug
report to gcc-bugs@gcc.gnu.org including:

    - The gcc version 
    - The system type
    - All options you passed to gcc
    - Preprocessed output of the source file that caused the compiler error 

All this can normally be accomplished by mailing the command line, the output
of the command, and the resulting `your-file.i' for C, or `your-file.ii' for
C++, corresponding to:

    gcc -v --save-temps all-your-options your-file.c 

Typically the CPP output will be large, so please compress the resulting file
with one of the popular compression programs such as gzip, bzip2, compress or
pkzip, then include the compressed CPP output as an attachment to your message.

The gcc lists have message size limits (100 kbytes) and bug reports over
those limits will currently be bounced. We're trying to find a way to allow
larger bug reports to be posted, but this is currently impossible. So,
although we prefer to have complete bug reports archived, if you cannot reduce
the bug report below the limit, please make it available for ftp or http and
post the URL.

Known Bugs and Non-Bugs
-----------------------

[Please see /usr/share/doc/gcc/FAQ or http://gcc.gnu.org/faq.html first]


C++ exceptions don't work with C libraries
------------------------------------------

[Taken from the closed bug report #22769] C++ exceptions don't work
with C libraries, if the C code wasn't designed to be thrown through.
A solution could be to translate all C libraries with -fexceptions.
Mostly trying to throw an exception in a callback function (qsort,
Tcl command callbacks, etc ...). Example:

    #include <stdio.h>
    #include <tcl.h>

    class A {};

    static
    int SortCondition(void const*, void const*)
    {
        printf("throwing 'sortcondition' exception\n");
        throw A();
    }

    int main(int argc, char *argv[])
    {
        int list[2];

        try {
            SortCondition(NULL,NULL);
        } catch (A) {
            printf("caught test-sortcondition exception\n");
        }
        try {
            qsort(&list, sizeof(list)/sizeof(list[0]),sizeof(list[0]),
                 &SortCondition);
        } catch (A) {
            printf("caught real-sortcondition exception\n");
        }
        return 0;
}

Andrew Macleod <amacleod@cygnus.com> responded:

When compiled with the table driven exception handling, exception can only
be thrown through functions which have been compiled with the table driven EH.
If a function isn't compiled that way, then we do not have the frame
unwinding information required to restore the registers when unwinding.

I believe the setjmp/longjmp mechanism will throw through things like this, 
but its produces much messier code.  (-fsjlj-exceptions)

The C compiler does support exceptions, you just have to turn them on
with -fexceptions.

Your main options are to:
  a) Don't use callbacks, or at least don't throw through them.
  b) Get the source and compile the library with -fexceptions (You have to
     explicitly turn on exceptions in the C compiler)
  c) always use -fsjlj-exceptions (boo, bad choice :-)


g++: "undefined reference" to static const array in class
---------------------------------------------------------

The following code compiles under GNU C++ 2.7.2 with correct results,
but produces the same linker error with GNU C++ 2.95.2.
Alexandre Oliva <oliva@lsd.ic.unicamp.br> responded:

All of them are correct.  A static data member *must* be defined
outside the class body even if it is initialized within the class
body, but no diagnostic is required if the definition is missing.  It
turns out that some releases do emit references to the missing symbol,
while others optimize it away.

#include <iostream>

class Test
{
  public:
    Test(const char *q);
  protected:
    static const unsigned char  Jam_signature[4]   = "JAM";
};

Test::Test(const char *q)
{
  if (memcmp(q, Jam_signature, sizeof(Jam_signature)) != 0)
  cerr << "Hello world!\n";
}

int main(void)
{
  Test::Test("JAM");
  return 0;
}

g++: g++ causes passing non const ptr to ptr to a func with const arg
     to cause an error (not a bug)
---------------------------------------------------------------------

Example:

#include <stdio.h>
void test(const char **b){
        printf ("%s\n",*b);
}
int main(void){
        char *test1="aoeu";
        test(&test1);
}

make const
g++     const.cc   -o const
const.cc: In function `int main()':
const.cc:7: passing `char **' as argument 1 of `test(const char **)' adds cv-quals without intervening `const'
make: *** [const] Error 1

Answer from "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>:

> ok... maybe I missed something.. I haven't really kept up with the latest in
> C++ news.  But I've never heard anything even remotly close to passing a non
> const var into a const arg being an error before.

Thanks for your bug report. This is a not a bug in the compiler, but
in your code. The standard, in 4.4/4, puts it that way

# A conversion can add cv-qualifiers at levels other than the first in
# multi-level pointers, subject to the following rules:
# Two pointer types T1 and T2 are similar if there exists a type T and
# integer n > 0 such that:
#   T1 is cv(1,0) pointer to cv(1,1) pointer to ... cv(1,n-1)
#   pointer to cv(1,n) T
# and
#   T2 is cv(2,0) pointer to cv(2,1) pointer to ... cv(2,n-1)
#   pointer to cv(2,n) T
# where each cv(i,j) is const, volatile, const volatile, or
# nothing. The n-tuple of cv-qualifiers after the first in a pointer
# type, e.g., cv(1,1) , cv(1,2) , ... , cv(1,n) in the pointer type
# T1, is called the cv-qualification signature of the pointer type. An
# expression of type T1 can be converted to type T2 if and only if the
# following conditions are satisfied:
#  - the pointer types are similar.
#  - for every j > 0, if const is in cv(1,j) then const is in cv(2,j) ,
#    and similarly for volatile.
#  - if the cv(1,j) and cv(2,j) are different, then const is in every
#    cv(2,k) for 0 < k < j.

It is the last rule that your code violates. The standard gives then
the following example as a rationale:

# [Note: if a program could assign a pointer of type T** to a pointer
# of type const T** (that is, if line //1 below was allowed), a
# program could inadvertently modify a const object (as it is done on
# line //2). For example,
# int main() { 
#   const char c = 'c'; 
#   char* pc; 
#   const char** pcc = &pc; //1: not allowed 
#   *pcc = &c; 
#   *pc = 'C'; //2: modifies a const object 
# }
# - end note]

If you question this line of reasoning, please discuss it in one of
the public C++ fora first, eg. comp.lang.c++.moderated, or
comp.std.c++.


cpp removes blank lines
-----------------------

With the new cpp, you need to add -traditional to the "cpp -P" args, else 
blank lines get removed.

[EDIT ME: scan Debian bug reports and write some nice summaries ...]