[Issue 3609] isNumeric causes a stack overlfow with mutable arrays

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3609


Andrei Alexandrescu <andrei at metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei at metalanguage.com


--- Comment #2 from Andrei Alexandrescu <andrei at metalanguage.com> 2009-12-11 21:24:55 PST ---
(In reply to comment #1)
> I ran into this a few days, too and was meaning to file it.  isNumeric is
> **completely** busted on D2, and it amazes me that noone noticed it until now. 
> The problem is that isNumeric(string, bool) is overloaded against
> isNumeric(...).  In D1, string is an alias for char[].  In D2, it's an alias
> for immutable(char)[].  If the type that's input is not a string, it's sent to
> isNumeric(...).  If it's a mutable char[] array in D2, the following is
> executed:
> 
>     if (_arguments[0] == typeid(char[]))
>         return isNumeric(va_arg!(char[])(_argptr));
> 
> Obviously, the intent here is to call the overload, but in D2 the overload
> expects an immutable(char)[], leading to isNumeric(...) getting called again. 
> Violia, infinite recursion and stack overflows.
> 
> I doubt anyone actually uses isNumeric(...), because its functionality should
> really be handled at compile time w/ templates.  I doubt there are too many use
> cases for having it be handled at runtime.  Therefore, I recommend dumping it
> and templating isNumeric(string) to handle char[], wchar[], dchar[], and the
> const and immutable flavors of these.  This would also fix bug 3610.

IMHO it's kind of silly to define isNumeric. It does about the same amount of
work as to, but doesn't give you the actual number. I suggest we just yank it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------