www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3669] New: Default parameter initialization of size_t can result in errors about implicit conversions to uint

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3669

           Summary: Default parameter initialization of size_t can result
                    in errors about implicit conversions to uint
           Product: D
           Version: 2.038
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: jmdavisProg gmail.com


--- Comment #0 from Jonathan M Davis <jmdavisProg gmail.com> 2010-01-03
20:28:01 PST ---
Okay. Basically, under some circumstances, a default initialization for a
function parameter of type size_t with an argument of type size_t results in a
complaint about uint not being convertible to size_t. For instance, given the
following code:

size_t getNum(size_t num = DEF_NUM)
{
    return num;
}

void main()
{
    size_t num = getNum();
}

size_t DEF_NUM = 10;

you get the error

temp.d(5): Error: cannot implicitly convert expression (DEF_NUM) of type size_t
to uint

However, if you put the declaration of DEF_NUM first:

size_t DEF_NUM = 10;

size_t getNum(size_t num = DEF_NUM)
{
    return num;
}

void main()
{
    size_t num = getNum();
}

it will compile. So, it appears to have something to do with the declaration
order. If you were to replace getNum() with DEF_NUM, that is

void main()
{
    size_t num = DEF_NUM;
}

size_t DEF_NUM = 10;

then it compiles. It doesn't matter whether DEF_NUM or main is declared first,
it compiles either way. So, it appears to have something to do with default
initialization of a function parameter. In any case, all of the variables
involved are size_t, so there shouldn't be any complaints about conversions. I
assume that size_t is actually uint and that there's some kind of aliasing
issue, but I don't know.

The compiler version that I'm using is actually 2.0.39, not 2.0.38, but 2.0.39
wasn't in the list - too new I guess. Also, my machine is x86_64, so I put
x86_64 for the hardware, but since dmd is only 32 bit, I doubt that it matters.
But that's my hardware, so that's what I put.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 03 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3669


Brad Roberts <braddr puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|x86_64                      |x86


--- Comment #1 from Brad Roberts <braddr puremagic.com> 2011-02-06 15:40:06 PST
---
Mass migration of bugs marked as x86-64 to just x86.  The platform run on isn't
what's relevant, it's if the app is a 32 or 64 bit app.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 06 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3669


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |yebblies gmail.com
         Resolution|                            |FIXED


--- Comment #2 from yebblies <yebblies gmail.com> 2011-06-16 01:11:47 PDT ---
Compiles successfully on dmd 2.053

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