Thiago Adams <thiago.adams@gmail.com> writes:

> On Friday, October 22, 2021 at 6:36:00 PM UTC-3, Ben Bacarisse wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>>
>> > The problem is to join typedefs of typedefs ...
>> > like:
>> > typedef char* const T1[5];
>> > typedef const T1 *T2[2];
>> >
>> > I want the type of T2 "expanded" with no typedefs to be able to
>> > compare types.
>> For C++ (which has typeid) both of these should work because neither has
>> a top-level const qualification.
>>
>> This is a bad topic for comp.lang.c because you seem to be working in
>> C++ and the two languages are patricularly far apart on this topic.
>
> The question is not about C++ typedid etc..

It appeared to be, since you posted C++ that included <typeinfo>! I got
the wrong end of the stick.

> It is about how to "expand" the type T3 (for instance) to a type
> without typedefs or in other words expand to the equivalent type or
> real type.

The word "expand" in quotes is a bit vague. You don't want code that
prints any types, you just want to be know (maybe by using an informal
algorithm) how to write a type defined with one or more typedefs without
any typedefs. Is that what you mean?

> typedef void* (*T1)(char, char);
> typedef const T1 (*T2)(double);
> typedef volatile T2 (*T3)[3];
>
> I was using gcc/c++ facilities just to print the type. (In the middle of test
> const behavior - my mistake - added some noise to the topic.) A derived topic
> was the const behavior with _Generic as well.

Ah, I thought you wanted code to "expand" the type into a text string.

--
Ben.

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>how to "expand" the type T3 (for instance) to a type without typedefs
>One can omit the "const" on the return type, so it's
>void * (* (* volatile (*)[3])(double))(char, char).

Here is the procedure:

typedef volatile T2 (*T3)[3]

means:

T3 = a pointer to an array of three volatile T2. (1)

and

typedef T1 (*T2)(double)

means:

T2 = a pointer to a function of double returning T1. (a)

Now, insert (a) into (1) to obtain:

T3 = a pointer to an array of three volatile
pointers to a function of double returning T1. (2)

Or,

typedef T1( *volatile( *T3a )[ 3 ])( double );

Next, step:

typedef void* (*T1)(char, char)

T1 = a pointer to a function of two chars yielding a void*. (b)

Now, insert the definition (b) into the (2) to obtain:

T3 = a pointer to an array of three volatile
pointers to a function of double returning
a pointer to a function of two chars yielding a void*. (3)

Or,

typedef void * (* (* volatile (*T3)[3])(double))(char, char)

, which declares T3 to have the type

void * (* (* volatile (*)[3])(double))(char, char)

. The famous program cdecl also can help to understand such
issues.

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>. The famous program cdecl also can help to understand such
>issues.

I assume that before posting you (Thiago) already have
checked the FAQ with sections like

|1.21: How do I construct and understand declarations of complicated
| types such as "array of N pointers to functions returning
| pointers to functions returning pointers to char"?

, so that's why I have not mentioned the FAQ!

On Friday, October 22, 2021 at 8:33:49 PM UTC-3, Ben Bacarisse wrote:
....
> > typedef void* (*T1)(char, char);
> > typedef const T1 (*T2)(double);
> > typedef volatile T2 (*T3)[3];
> >
> > I was using gcc/c++ facilities just to print the type. (In the middle of test
> > const behavior - my mistake - added some noise to the topic.) A derived topic
> > was the const behavior with _Generic as well.
> Ah, I thought you wanted code to "expand" the type into a text string.

I guess for text representation this algorithm works:
We want to know the type of T3.

Because T3 uses T2:
Remove specifiers from T3
volatile (*T3)[3];

Because T2 uses T1:
Remove specifiers from T2

const (*T2)(double);

Copy T3 into T2 type-name.
const (* volatile (*T3)[3] )(double);

Do not remove specifiers of T1 because they are not type-name

Copy T2 result into T1 type-name
void* (*T1)(char, char);

Result:
void* (*const (* volatile (*T3)[3] )(double))(char, char);

On 23/10/2021 15:57, Thiago Adams wrote:
> On Friday, October 22, 2021 at 8:33:49 PM UTC-3, Ben Bacarisse wrote:
> ...
>>> typedef void* (*T1)(char, char);
>>> typedef const T1 (*T2)(double);
>>> typedef volatile T2 (*T3)[3];
>>>
>>> I was using gcc/c++ facilities just to print the type. (In the middle of test
>>> const behavior - my mistake - added some noise to the topic.) A derived topic
>>> was the const behavior with _Generic as well.
>> Ah, I thought you wanted code to "expand" the type into a text string.
>
> I guess for text representation this algorithm works:
> We want to know the type of T3.
>
> Because T3 uses T2:
> Remove specifiers from T3
> volatile (*T3)[3];
>
> Because T2 uses T1:
> Remove specifiers from T2
>
> const (*T2)(double);
>
> Copy T3 into T2 type-name.
> const (* volatile (*T3)[3] )(double);
>
> Do not remove specifiers of T1 because they are not type-name
>
> Copy T2 result into T1 type-name
> void* (*T1)(char, char);
>
> Result:
> void* (*const (* volatile (*T3)[3] )(double))(char, char);
>

I couldn't follow that at all.

However, are you using a proper parser, or is this all done with
text-processing?

Because any typedef statement can have multiple T2s (as struct tags,
struct fields, parameter names, as well as a typedef).

I would assume you are since it would be impossible otherwise. But if
so, the issue with flattening typedefs is puzzling.

Given an internal, structured representation of a C type, the algorithm
you want is one for recreating the type as text in C syntax.

The process of parsing the typedefs should already have elimated any
embedded typedefs, so that by the time you get to T3, the representation
of its type should not mention T1 or T2.

On Saturday, October 23, 2021 at 6:11:33 PM UTC-3, Bart wrote:
> On 23/10/2021 15:57, Thiago Adams wrote:
> > On Friday, October 22, 2021 at 8:33:49 PM UTC-3, Ben Bacarisse wrote:
> > ...
> >>> typedef void* (*T1)(char, char);
> >>> typedef const T1 (*T2)(double);
> >>> typedef volatile T2 (*T3)[3];
> >>>
> >>> I was using gcc/c++ facilities just to print the type. (In the middle of test
> >>> const behavior - my mistake - added some noise to the topic.) A derived topic
> >>> was the const behavior with _Generic as well.
> >> Ah, I thought you wanted code to "expand" the type into a text string.
> >
> > I guess for text representation this algorithm works:
> > We want to know the type of T3.
> >
> > Because T3 uses T2:
> > Remove specifiers from T3
> > volatile (*T3)[3];
> >
> > Because T2 uses T1:
> > Remove specifiers from T2
> >
> > const (*T2)(double);
> >
> > Copy T3 into T2 type-name.
> > const (* volatile (*T3)[3] )(double);
> >
> > Do not remove specifiers of T1 because they are not type-name
> >
> > Copy T2 result into T1 type-name
> > void* (*T1)(char, char);
> >
> > Result:
> > void* (*const (* volatile (*T3)[3] )(double))(char, char);
> >
> I couldn't follow that at all.
>
> However, are you using a proper parser, or is this all done with
> text-processing?

I have the parser , I have the ast.
I thought this textual algorithm would be more on topic here.

> Because any typedef statement can have multiple T2s (as struct tags,
> struct fields, parameter names, as well as a typedef).

yes. I represent types using the C "type-name" that consists
on declarator and list of specifiers qualifiers. This can represent the complex
declarations.
> I would assume you are since it would be impossible otherwise. But if
> so, the issue with flattening typedefs is puzzling.
>
> Given an internal, structured representation of a C type, the algorithm
> you want is one for recreating the type as text in C syntax.
> The process of parsing the typedefs should already have elimated any
> embedded typedefs, so that by the time you get to T3, the representation
> of its type should not mention T1 or T2.

Do you mean you remove dependent typedefs as soon as you parse?

My objective is add type checks in my compiler, checks arguments, return types,
etc. For this task I want to "normalize" the types so I can compare then using the
normalized version.

I need to create this algorithm to normalize typedefs depending on other typedefs
but this does not look so obvious.