[Rock-dev] Typleib and Builtins...

[Janosch Machowinski]

Hey,
I stumbled over the builtin (or Fundamental) types.
In the concrete case it is about the char type.
GCCXML as well as clang report char as own
type, being (platform dependent) a signed or unsigned
numeric with 8 bits.
They also report a own type for signed char and unsigned
char.

Debugging my way through typlib I found out, that before,
only intX_t were registered, and char, short etc were
aliases to intX_t.

And this is were the trouble starts. As stdint.h
defines a typedf signed char int8_t;.
If I try to register this typedef, I get an error,
that int8_t is already defined in the registry.
Or I get it later on, if I try to merge my registry
with orogen default registry.

I would vote for removing the whole code in
standard_types.cc, and do the builtin recovery
completely by parsing stdint.h or a similar header.

Coming back to the signed char / unsigned char / char
thing above. Is it actually allowed by design (of typelib),
to have theses three types in the registry not aliased ?
(char being an alias of either signed or unsigned char)
Greetings
Janosch
--
Dipl. Inf. Janosch Machowinski
SAR- & Sicherheitsrobotik

Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Zentrale: [phone]

Besuchsadresse der Nebengesch?ftstelle:
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Tel.: [phone]
Empfang: [phone]
Fax: [phone]
E-Mail: jmachowinski at informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

[Sylvain Joyeux]

Post by Janosch Machowinski
Coming back to the signed char / unsigned char / char
thing above. Is it actually allowed by design (of typelib),
to have theses three types in the registry not aliased ?
(char being an alias of either signed or unsigned char)

Yes, and it should stay that way. Typelib fundamental types are this
way represented as the non-ambiguous (u)intX_t type names instead of
the ambiguous normal C names. It requires a little bit more work on
the importer side, but that is in my opinion worth it.

Basically, there are two ways in the importer:
- either directly translate numerical types into the non-ambiguous naming
- or initialize the importer's registry with typelib's "standard
C/C++ types". The importer would then avoid resolving them as they are
already present in the registry.

Sylvain

[Janosch Machowinski]

Post by Sylvain Joyeux

Post by Janosch Machowinski
Coming back to the signed char / unsigned char / char
thing above. Is it actually allowed by design (of typelib),
to have theses three types in the registry not aliased ?
(char being an alias of either signed or unsigned char)

Yes, and it should stay that way. Typelib fundamental types are this
way represented as the non-ambiguous (u)intX_t type names instead of
the ambiguous normal C names. It requires a little bit more work on
the importer side, but that is in my opinion worth it.

Uhm, your answer is ambiguous. So, is it possible, to haven
signed char / unsigned char / char as three separate Numerics
registered ?

I am not sure, if there is a real gain of using intX_t types. In the
end it is a test on if the type is a Numeric with or without signess
and a certain bit width, as do_compare ignores the type name
completely.

Post by Sylvain Joyeux
- either directly translate numerical types into the non-ambiguous naming
- or initialize the importer's registry with typelib's "standard
C/C++ types". The importer would then avoid resolving them as they are
already present in the registry.

Hm, in the clang importer I just register the builtins as
their corresponding numerics, as I get information about
signess, and bitwidth. I saw, that GCCXML did not give any information
about the sign though.
I like this solution, as I need no apriori information for building
a registry.
Greetings
Janosch

[Janosch Machowinski]

Post by Janosch Machowinski
Hm, in the clang importer I just register the builtins as
their corresponding numerics, as I get information about
signess, and bitwidth. I saw, that GCCXML did not give any information
about the sign though.
I like this solution, as I need no apriori information for building
a registry.

I just remembered another advantage of this approach, Martin told me
about today. Atm it is possible to give the clang-tlb-tool a target
architecture
as parameter and cross generate tlb files for e.g. ARM. This might be an
interresting use case for us. (For Martin it is THE use case).
Greetings
Janosch

[Sylvain Joyeux]

Post by Janosch Machowinski
Uhm, your answer is ambiguous. So, is it possible, to haven
signed char / unsigned char / char as three separate Numerics
registered ?

Would be possible but definitely not what I had in mind.

What typelib does so far is ensure that all numeric types have a
normalized name, but still provide the relevant aliases.

Post by Janosch Machowinski
I am not sure, if there is a real gain of using intX_t types. In the
end it is a test on if the type is a Numeric with or without signess
and a certain bit width, as do_compare ignores the type name
completely.

There's no gain for typelib, there is a huge gain for the user as one
will not have two different fundamental types named the same in two
separate registries.

Sylvain

[Martin Zenzes]

Post by Sylvain Joyeux

Post by Janosch Machowinski
Coming back to the signed char / unsigned char / char
thing above. Is it actually allowed by design (of typelib),
to have theses three types in the registry not aliased ?
(char being an alias of either signed or unsigned char)

Yes, and it should stay that way. Typelib fundamental types are this
way represented as the non-ambiguous (u)intX_t type names instead of
the ambiguous normal C names. It requires a little bit more work on
the importer side, but that is in my opinion worth it.
- either directly translate numerical types into the non-ambiguous naming
- or initialize the importer's registry with typelib's "standard
C/C++ types". The importer would then avoid resolving them as they are
already present in the registry.

Having hardcoded types or mapping somewhere in the registry smells like
a bad solution. The importer should be able to figure out everything,
since in the end its a compiler, which knows the language better than
us. This also allows switching the target-arch for parsing (as Janosch
mentioned earlier) for example.

Having this mapping from "char" to "(u)int8" hardcoded somewhere is
arch-specific. As soon as an ARM talks to an x86 both would use the same
hardcoded mapping for chars (ints). They could talk to each other with
messages containing chars (or ints) while typelib should prevent it in
the first place, because they are different on the two machines?

Post by Sylvain Joyeux
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
M.Sc. Martin Zenzes
Space Robotics

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Phone: [phone] - 6658
Fax: [phone] - 4150
E-Mail: martin.zenzes at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

[Sylvain Joyeux]

Post by Martin Zenzes
Having hardcoded types or mapping somewhere in the registry smells like
a bad solution. The importer should be able to figure out everything,
since in the end its a compiler, which knows the language better than
us. This also allows switching the target-arch for parsing (as Janosch
mentioned earlier) for example.

It does NOT have to be hardcoded. The importer can produce the exact
same behaviour than add_standard_cxx_types, that is making sure that
it names all numeric types in the normalized way and creates the
proper aliases. It was solution (1).

add_standard_cxx_types is *definitely* arch-specific, and works only
for the local arch. You can see for yourself, it makes sure that char
is properly defined as signed/unsigned depending on the local target.

In any case, we do NOT have to use add_standard_cxx_types in the clang
importer since it can deduce the same information itself.

Post by Martin Zenzes
Having this mapping from "char" to "(u)int8" hardcoded somewhere is
arch-specific. As soon as an ARM talks to an x86 both would use the same
hardcoded mapping for chars (ints). They could talk to each other with
messages containing chars (or ints) while typelib should prevent it in
the first place, because they are different on the two machines?

It would generate an error, yes.

Sylvain