This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: [PATCH] PR libstdc++/13045 / C++ demangler, floating values and function pointer type return type postfix fix.


On Wed, Nov 26, 2003 at 05:34:34AM +0100, Gabriel Dos Reis wrote:
> It will not work. One reason was explained by DJ.

What reason was that?  I cannot remember to have read any
valid reason from him.  Please include DETAILS in your
mails or we will not get anywhere. (like this:)

If you are refering to his remark in
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02054.html
then you didn't read my original proposal either.

Perhaps I am too mathematical orientated; when I talk
about a one-on-one bijection, then I use the words
"*exactly* as typed by the programmer", because in my
mind, a 100% reversable one-on-one character translation
is it is equivalent, there is no difference abstractly
seen.  Sorry if I was unclear in my choice of words;
nevertheless, I was more then clear in my examples later
in that same post.

> Another is that
> it does not reduce to a normal form before outputing leading to many
> symbols being thought different while they are the same.

But is that really a problem?  Because when it is a problem
then there a lot more problems just around the corner (see below).

> It is not like no other concrete and praticable proposal was made.
> 
> The C99 hex floating notation notation with the constraints
>   (1) no trailing zero for mantissa
>   (2) no leading zero for exponent
> gives a normal form (or pretty close -- double check).
> It has the advantage of being target independent.

That is not correct.  On different targets, this can result in
different symbols.  For example, a floating point value that cannot
be represented in a finite number of binary bits will result in
different symbols depending on the precision of a double on that target.

For example, suppose the programmer types in the source code: "1.234".
Then on one target that could result in:
1.3BE76C9 and on another 1.3BE76C8B43958
the demangler would translate the last one into:

1.234  (because it is 1.2339999999999999857...,
                                       ^__ last digit needed for given
				           precision.
which is 1.234 rounded off), and the first one into:
1.234000001 (The last digit is needed in order to discriminate between
1.3BE76C9 and 1.3BE76C8, for example).

In otherwords, the mangled and demangled names would be different
depending on the target.

This is a direct result of rounding off and varying precision on different
targets that cannot be avoided when you use a hex representation instead
of a decimal representation.

-- 
Carlo Wood <carlo@alinoe.com>


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