Alberto Lozano Alelu a écrit:
> When I get a typedef, I would like to show the definition. I use:
>
> tree v_next_type=DECL_ORIGINAL_TYPE(TYPE_NAME(v_type));
>
> But this expression isn't always correct.
You are correct. There are times where typedefs are thrown away
(st
Hello.
First at all. This is my first message in this mailing list.
I'm developing a static source analyzer from c++ frontend (in future
it will be a gcc plugin) and I get problems when I access to type of
typedef.
When I get a typedef, I would like to show the definition. I use:
tree v_next_type
On Thu, 17 Jan 2008, Taras Glek wrote:
| Major Issue: Specifying TFF_CHASE_TYPEDEFS as a parameter only works with
| top-level typenames because the C/C++ pretty printing code does not
| support/propagate the flags parameter. Is this considered a bug or a TODO?
| Would a patch to move the TFF* fla
Hi,
I am working on a static analysis plugin for Mozilla. I noticed the the
C++ frontend has a very convenient pretty-printing API exposed through
(decl|type)_as_string. I use decl_as_string() to get string
representations of types. The scripts are interested in both kinds of
types: the type n
Hello,
in debugging a failing GDB test case I've come upon what looks like bad
DWARF-2 debug info being generated by G++.
The problem has to do with typedefs of anonymous structs like:
typedef struct {
int one;
int two;
} tagless_struct;
tagless_struct v_tagless;
This causes the foll
On Nov 27, 2006, at 12:49 PM, Brendon Costa wrote:
As a result of C types not having a "class name for linkage
purposes", I
am finding it difficult to define a "normalised" string
Trivially, you can construct the name by composing one based upon the
structure. The is_compatible function th
Andrew Pinski wrote:
> Again C has different rules from C++.
> In C, the following two TUs combined together are still valid code while in
> C++,
> they are invalid.
>
> tu1.c:
>
> struct a
> {
> int t;
> };
> void f(struct a);
>
> cut -
> tu2.c:
>
> type
>
> Gabriel Dos Reis wrote:
> > C++ defines a notion of "class name for linkage purpose" -- that is a
> > notion used to define the One Definition Rule.
> > In general the TYPE_NAME of TYPE_MAIN_VARIANT is the class name for
> > linkage purpose.
> > The behaviour you reported on implements the
Gabriel Dos Reis wrote:
> C++ defines a notion of "class name for linkage purpose" -- that is a
> notion used to define the One Definition Rule.
> In general the TYPE_NAME of TYPE_MAIN_VARIANT is the class name for
> linkage purpose.
> The behaviour you reported on implements the rule 7.1.3/5:
>
Brendon Costa <[EMAIL PROTECTED]> writes:
| Hi all,
|
| I have just come across a small difference in the way the C an C++
| front ends handle anonymous struct types which is causing me some
| grief. In particular the following code:
|
| typedef struct
| {
| int b1;
| int b2;
| } Blah;
|
On Mon, 2006-11-27 at 12:02 +1100, Brendon Costa wrote:
> And apply the TYPE_MAIN_VARIANT on "Another", C++ returns Blah and C
> again returns the anonymous RECORD_TYPE. In my situation this is causing
> some grief as i need a consistent name for the main varient type across
> translation units.
Hi all,
I have just come across a small difference in the way the C an C++ front
ends handle anonymous struct types which is causing me some grief. In
particular the following code:
typedef struct
{
int b1;
int b2;
} Blah;
void Function(Blah* b) {}
When i get the Blah type in the func
Giovanni Bajo wrote:
> Manu Abraham wrote:
>
>> When one does a
>>
>> typedef uint8_t array[10];
>>
>> what does really happen ?
>
> This question does not concern the development of the GCC compiler in any
> way
??? Unless, surely, the answer wanted was something along the lines of:
`Th
Manu Abraham <[EMAIL PROTECTED]> wrote:
> When one does a
>
> typedef uint8_t array[10];
>
> what does really happen ?
This question does not concern the development of the GCC compiler in any way,
so it does not belong here. Please post it to support forums for th eC
language.
Giovanni Bajo
Hi,
When one does a
typedef uint8_t array[10];
what does really happen ?
For example, i was looking at some code in the public domain, which had
it like this ..
u8 is again typedef'd from a unsigned char
#define TS_PACKET_SIZE 188
#define TS_IN_UDP 7
typedef u8 file_ts_packet[TS_PACKET_S
Gabriel Dos Reis wrote:
> Plain compiler bug. I'm not aware of any existing report to that
> effect, though GCC/g++ currently is completely confused when it sees
> apparently ambiguous declarations, and would report non-existent
> declaration. That needs fixing.
I have a patch-in-progress for t
> Plain compiler bug. I'm not aware of any existing report to that
> effect,
IMHO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9726
is the same bug
Joerg
Howard Hinnant <[EMAIL PROTECTED]> writes:
| Hi All,
|
| I'm wondering if the following behavior is:
|
| 1. An already reported bug.
| 2. Not reported, I need to file a bugzilla.
| 3. Disputed.
|
| Here's the test case:
|
| typedef unsigned short ushort;
|
| namespace X
| {
| typedef
ushort us = 0;
}
We currently get:
error: 'ushort' was not declared in this scope
The deal is that the typedef ushort is defined in two different
places, to the same type, and then brought "in conflict" via a using
declaration. But since the two typedefs refer to the
19 matches
Mail list logo
