This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] Be in language c more c++ compatible


>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> echo 'class C { typedef int t; t i; } c;'|g++ -c -o 1.o -g -x c++ -
Jan> FSF GDB HEAD
Jan> (gdb) show language 
Jan> The current source language is "auto; currently c".

I am curious why this happens.
It seems like it should say "currently c++" -- I didn't check the code
but my mental model would be that if there is no frame, then the default
symtab should either be 'main' or, if no main, say the first CU in the
symbol file; and the default symtab's language should be used for auto.

Jan> The first (c-exp.y) part parses those parts of `language c++' which cannot
Jan> (I believe - RFC) lead to misinterpretation of any valid C code even in
Jan> `language c'.

I think so, though one would have to check eval.c and friends as well to
be certain.

Jan> The second (valops.c) part is there because with `language c++'
Jan> parsing "C::t" is straight OP_TYPE handled correctly in
Jan> evaluate_subexp_standard.  But with `language c' it gets parsed as
Jan> OP_SCOPE and I find there a bug, copied the code there.

I don't even know why we have OP_SCOPE.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]