The ABI says this:

TemplateInstanceName:
     __T LName TemplateArgs Z

and I think it should be:

TemplateInstanceName:
     Number __T LName TemplateArgs Z

Any objection to my fixing it?

I'm not sure. See bug 3034 "Template instance name wrongly mangled as LName". I don't know if that bug report is valid -- is it legal to have a module name which starts with double underscores??? It does seem to be accepted, though.

We need to either change the spec and mark the bug as invalid, or else
change the compiler and leave the spec as-is.
Another related mangling bug is 3043 "Template symbol arg cannot be
demangled", which I think is probably invalid.

On 30 August 2010 21:20, Sean Kelly <sean at invisibleduck.org> wrote:
> The ABI says this:
>
> TemplateInstanceName:
> ? ? __T LName TemplateArgs Z
>
> and I think it should be:
>
> TemplateInstanceName:
> ? ? Number __T LName TemplateArgs Z
>
> Any objection to my fixing it?
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

I'd love for the current scheme to be considered a bug because it requires arbitrary lookahead to determine whether a symbol represents a template (see demangle.parseSymbolName, for example).  If the leading Number were removed then testing for template vs. LName would basically be a matter of checking for a digit vs. underscore.  For symbol names I've always followed C conventions, but I don't think the compiler restricts symbol names at all.

On Aug 30, 2010, at 1:00 PM, Don Clugston wrote:

> I'm not sure. See bug 3034 "Template instance name wrongly mangled as LName". I don't know if that bug report is valid -- is it legal to have a module name which starts with double underscores??? It does seem to be accepted, though.
> 
> We need to either change the spec and mark the bug as invalid, or else
> change the compiler and leave the spec as-is.
> Another related mangling bug is 3043 "Template symbol arg cannot be
> demangled", which I think is probably invalid.
> 
> On 30 August 2010 21:20, Sean Kelly <sean at invisibleduck.org> wrote:
>> The ABI says this:
>> 
>> TemplateInstanceName:
>>     __T LName TemplateArgs Z
>> 
>> and I think it should be:
>> 
>> TemplateInstanceName:
>>     Number __T LName TemplateArgs Z
>> 
>> Any objection to my fixing it?
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>> 
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

One other thing.  The ABI has "i Number" under "Value" for templates, but demangle() doesn't handle this and the ABI is totally silent on what it is.  Any idea?  I suppose I could just check the DMD source though.

On Aug 30, 2010, at 2:22 PM, Sean Kelly wrote:

> I'd love for the current scheme to be considered a bug because it requires arbitrary lookahead to determine whether a symbol represents a template (see demangle.parseSymbolName, for example).  If the leading Number were removed then testing for template vs. LName would basically be a matter of checking for a digit vs. underscore.  For symbol names I've always followed C conventions, but I don't think the compiler restricts symbol names at all.
> 
> On Aug 30, 2010, at 1:00 PM, Don Clugston wrote:
> 
>> I'm not sure. See bug 3034 "Template instance name wrongly mangled as LName". I don't know if that bug report is valid -- is it legal to have a module name which starts with double underscores??? It does seem to be accepted, though.
>> 
>> We need to either change the spec and mark the bug as invalid, or else
>> change the compiler and leave the spec as-is.
>> Another related mangling bug is 3043 "Template symbol arg cannot be
>> demangled", which I think is probably invalid.
>> 
>> On 30 August 2010 21:20, Sean Kelly <sean at invisibleduck.org> wrote:
>>> The ABI says this:
>>> 
>>> TemplateInstanceName:
>>>    __T LName TemplateArgs Z
>>> 
>>> and I think it should be:
>>> 
>>> TemplateInstanceName:
>>>    Number __T LName TemplateArgs Z
>>> 
>>> Any objection to my fixing it?
>>> _______________________________________________
>>> dmd-internals mailing list
>>> dmd-internals at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>> 
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> 
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 31 August 2010 05:58, Sean Kelly <sean at invisibleduck.org> wrote:
> One other thing. ?The ABI has "i Number" under "Value" for templates, but demangle() doesn't handle this and the ABI is totally silent on what it is. ?Any idea? ?I suppose I could just check the DMD source though.

Svn 370. Which I think was a really bad idea. The i should always be there, for any positive number. It's a fantasy to think that the ABI is stable at this point (eg, bug 3398 "Attributes inside a union screws data alignment" has only just been fixed). We could fix all remaining ABI issues in one go, then declare it stable.

Comment from the code:
	/* This is an awful hack to maintain backwards compatibility.
	 * There really always should be an 'i' before a number, but
	 * there wasn't in earlier implementations, so to maintain
	 * backwards compatibility it is only done if necessary to disambiguate.
	 * See bugzilla 3029
	 */

>
> On Aug 30, 2010, at 2:22 PM, Sean Kelly wrote:
>
>> I'd love for the current scheme to be considered a bug because it requires arbitrary lookahead to determine whether a symbol represents a template (see demangle.parseSymbolName, for example). ?If the leading Number were removed then testing for template vs. LName would basically be a matter of checking for a digit vs. underscore. ?For symbol names I've always followed C conventions, but I don't think the compiler restricts symbol names at all.
>>
>> On Aug 30, 2010, at 1:00 PM, Don Clugston wrote:
>>
>>> I'm not sure. See bug 3034 "Template instance name wrongly mangled as LName". I don't know if that bug report is valid -- is it legal to have a module name which starts with double underscores??? It does seem to be accepted, though.
>>>
>>> We need to either change the spec and mark the bug as invalid, or else
>>> change the compiler and leave the spec as-is.
>>> Another related mangling bug is 3043 "Template symbol arg cannot be
>>> demangled", which I think is probably invalid.
>>>
>>> On 30 August 2010 21:20, Sean Kelly <sean at invisibleduck.org> wrote:
>>>> The ABI says this:
>>>>
>>>> TemplateInstanceName:
>>>> ? ?__T LName TemplateArgs Z
>>>>
>>>> and I think it should be:
>>>>
>>>> TemplateInstanceName:
>>>> ? ?Number __T LName TemplateArgs Z
>>>>
>>>> Any objection to my fixing it?
>>>> _______________________________________________
>>>> dmd-internals mailing list
>>>> dmd-internals at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>>>
>>> _______________________________________________
>>> dmd-internals mailing list
>>> dmd-internals at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

Well that explains that parsing ambiguity. I guess the unqualified "Number" value would go away then.

Sent from my iPhone

On Aug 31, 2010, at 12:06 AM, Don Clugston <dclugston at googlemail.com> wrote:

> On 31 August 2010 05:58, Sean Kelly <sean at invisibleduck.org> wrote:
>> One other thing.  The ABI has "i Number" under "Value" for templates, but demangle() doesn't handle this and the ABI is totally silent on what it is.  Any idea?  I suppose I could just check the DMD source though.
> 
> Svn 370. Which I think was a really bad idea. The i should always be there, for any positive number. It's a fantasy to think that the ABI is stable at this point (eg, bug 3398 "Attributes inside a union screws data alignment" has only just been fixed). We could fix all remaining ABI issues in one go, then declare it stable.
> 
> Comment from the code:
>    /* This is an awful hack to maintain backwards compatibility.
>     * There really always should be an 'i' before a number, but
>     * there wasn't in earlier implementations, so to maintain
>     * backwards compatibility it is only done if necessary to disambiguate.
>     * See bugzilla 3029
>     */
> 
>> 
>> On Aug 30, 2010, at 2:22 PM, Sean Kelly wrote:
>> 
>>> I'd love for the current scheme to be considered a bug because it requires arbitrary lookahead to determine whether a symbol represents a template (see demangle.parseSymbolName, for example).  If the leading Number were removed then testing for template vs. LName would basically be a matter of checking for a digit vs. underscore.  For symbol names I've always followed C conventions, but I don't think the compiler restricts symbol names at all.
>>> 
>>> On Aug 30, 2010, at 1:00 PM, Don Clugston wrote:
>>> 
>>>> I'm not sure. See bug 3034 "Template instance name wrongly mangled as LName". I don't know if that bug report is valid -- is it legal to have a module name which starts with double underscores??? It does seem to be accepted, though.
>>>> 
>>>> We need to either change the spec and mark the bug as invalid, or else
>>>> change the compiler and leave the spec as-is.
>>>> Another related mangling bug is 3043 "Template symbol arg cannot be
>>>> demangled", which I think is probably invalid.
>>>> 
>>>> On 30 August 2010 21:20, Sean Kelly <sean at invisibleduck.org> wrote:
>>>>> The ABI says this:
>>>>> 
>>>>> TemplateInstanceName:
>>>>>    __T LName TemplateArgs Z
>>>>> 
>>>>> and I think it should be:
>>>>> 
>>>>> TemplateInstanceName:
>>>>>    Number __T LName TemplateArgs Z
>>>>> 
>>>>> Any objection to my fixing it?
>>>>> _______________________________________________
>>>>> dmd-internals mailing list
>>>>> dmd-internals at puremagic.com
>>>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>>>> 
>>>> _______________________________________________
>>>> dmd-internals mailing list
>>>> dmd-internals at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>> 
>>> _______________________________________________
>>> dmd-internals mailing list
>>> dmd-internals at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>> 
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>> 
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

> Svn 370. Which I think was a really bad idea. The i should always be there, for any positive number. It's a fantasy to think that the ABI is stable at this point (eg, bug 3398 "Attributes inside a union screws data alignment" has only just been fixed). We could fix all remaining ABI issues in one go, then declare it stable.

So is this going to be reverted?

This one is really more of a programming question, but it's mangling related so I figured I'd ask here anyway.  The following function:

    void someFunc(real x)() {}
    someFunc!(1234.5678);

is mangled as:

    D8demangle34__T8someFuncVde9A522B6AE7D566CFP7Z8someFuncFZv

std.demangle assumes that when it encounters an 'e' in a template parameter list, the next 20 bytes will be a hex representation of an 80 bit floating point value.  The ABI and current mangling behavior is to represent things a bit differently with a variable width hex mantissa and exponent value (HexDigits P Number).  So in this case I have 8 bytes of mantissa (9A 52 2B 6A E7 D5 66 CF) and 1 byte of exponent (7).  I'm having trouble relating the mangled value to 1234.5678 though.  Can someone explain what's going on here, and possibly suggest an appropriate means for converting the mangled value to a textual representation?

On 1 September 2010 21:35, Sean Kelly <sean at invisibleduck.org> wrote:
> This one is really more of a programming question, but it's mangling related so I figured I'd ask here anyway. ?The following function:
>
> ? ?void someFunc(real x)() {}
> ? ?someFunc!(1234.5678);
>
> is mangled as:
>
> ? ?D8demangle34__T8someFuncVde9A522B6AE7D566CFP7Z8someFuncFZv
>
> std.demangle assumes that when it encounters an 'e' in a template parameter list, the next 20 bytes will be a hex representation of an 80 bit floating point value. ?The ABI and current mangling behavior is to represent things a bit differently with a variable width hex mantissa and exponent value (HexDigits P Number). ?So in this case I have 8 bytes of mantissa (9A 52 2B 6A E7 D5 66 CF) and 1 byte of exponent (7). ?I'm having trouble relating the mangled value to 1234.5678 though. ?Can someone explain what's going on here, and possibly suggest an appropriate means for converting the mangled value to a textual representation?

The mangled value is just the %A representation of the number.
ulong u = 0x9A522B6AE7D566CFL;
writefln("%A  %X", 1234.5678L, (u<<1));
---prints---
0X1.34A456D5CFAACD9EP+10  34A456D5CFAACD9E
Note that the exponent is decimal, not hex.

Sean Kelly wrote:
> This one is really more of a programming question, but it's mangling related so I figured I'd ask here anyway.  The following function:
>
>     void someFunc(real x)() {}
>     someFunc!(1234.5678);
>
> is mangled as:
>
>     D8demangle34__T8someFuncVde9A522B6AE7D566CFP7Z8someFuncFZv
>
> std.demangle assumes that when it encounters an 'e' in a template parameter list, the next 20 bytes will be a hex representation of an 80 bit floating point value.  The ABI and current mangling behavior is to represent things a bit differently with a variable width hex mantissa and exponent value (HexDigits P Number).  So in this case I have 8 bytes of mantissa (9A 52 2B 6A E7 D5 66 CF) and 1 byte of exponent (7).  I'm having trouble relating the mangled value to 1234.5678 though.  Can someone explain what's going on here, and possibly suggest an appropriate means for converting the mangled value to a textual representation?
> 

The mangling is done with printf's %LA format. scanf should be able to reverse it.

void realToMangleBuffer(OutBuffer *buf, real_t value)
{
    /* Rely on %A to get portable mangling.
     * Must munge result to get only identifier characters
     *
     * Possible values from %A  => mangled result
     * NAN                      => NAN
     * -INF                     => NINF
     * INF                      => INF
     * -0X1.1BC18BA997B95P+79   => N11BC18BA997B95P79
     * 0X1.9P+2                 => 19P2
     */

#if 1
    if (Port::isNan(value))
#elif __APPLE__
    if (__inline_isnan(value))
#else
    if (isnan(value))
#endif
        buf->writestring("NAN");        // no -NAN bugs
    else
    {
        char buffer[32];
        int n = sprintf(buffer, "%LA", value);
        assert(n > 0 && n < sizeof(buffer));
        for (int i = 0; i < n; i++)
        {   char c = buffer[i];

            switch (c)
            {
                case '-':
                    buf->writeByte('N');
                    break;

                case '+':
                case 'X':
                case '.':
                    break;

                case '0':
                    if (i < 2)
                        break;          // skip leading 0X
                default:
                    buf->writeByte(c);
                    break;
            }
        }
    }
}