Re: [PATCH] PR libstdc++/13045 / C++ demangler, floating values and function pointer type return type postfix fix.

[Carlo Wood <carlo at alinoe dot com>]

On Tue, Nov 25, 2003 at 10:39:25AM -0800, Nathan Myers wrote:
> only need a representation for those literals that is compatible with 
> the linker's character set.  The key is that when a floating-point 
> value is a literal, it has a textual representation seen by the 
> compiler, and that's the one we're interested in.  There might be 
> some value in translating to a canonical format, so that 1e1, 10.0,
> and .1e2 end up encoded the same, but that seems optional.

Lets cut the knot.

Although your proposal is counter intuitive, I believe it
is the most logical thing to do: keep the mangling *exactly*
as whatever was typed by the programmer.

That means that 10.0 != 1e1, in terms of mangling.  And that
when someone types 1.000000000000000000000000000000000000000000000000000000000000001
then that is mangled exactly like that, and will be different
from 1.0.

Benefits:

- Easy to mangle.
- Easy demangle.
- Totally target indepedent.
- Ever compiler sticking to this ABI will produce the same
  symbols for the same code - independant on what platform
  is being compiled.

Disadvantage:

- A programmer might expect that typing 1e1 and 10.0 gives the
  same symbol, because the decimal value is the same.

But well, he might also expect that typeing 1.0 and -(-1.0)
gives the same results  - and it just doesn't.  He'll get used
to it.

Using a hexadecimal form just to compress is not an argument:
Only less than 0.00001% of Real Code uses float literals in
symbol names.  Using anything else but a character by character
translation of what is in the source code introduces problems.

So, the translation is (has to be) trivial:

+ = p
- = m

0-9 = 0-9

. = d

e/E = e/E

Ie:

  -34.908e-100  -->  m34d908em100

  +010.0E10      --> p010d0E10

straight forward and simple :).
And we need an '_' to detect the end.

Ldm34d908Em100_  --> literal double with value -34.908E-100

-- 
Carlo Wood <carlo@alinoe.com>