bearophile can say "i told you so" (re uint->int implicit conv)

Alex Rønne Petersen alex at lycus.org
Thu Mar 28 13:19:40 PDT 2013


On 28-03-2013 21:03, Adam D. Ruppe wrote:
> I was working on a project earlier today that stores IP addresses in a
> database as a uint. For some reason though, some addresses were coming
> out as 0.0.0.0, despite the fact that if(ip == 0) return; in the only
> place it actually saves them (which was my first attempted quick fix for
> the bug).
>
> Turns out the problem was this:
>
> if (arg == typeid(uint)) {
>      int e = va_arg!uint(_argptr);
>      a = to!string(e);
> }
>
>
> See, I copy/pasted it from the int check, but didn't update the type on
> the left hand side. So it correctly pulled a uint out of the varargs,
> but then assigned it to an int, which the compiler accepted silently, so
> to!string() printed -blah instead of bigblah... which then got truncated
> by the database, resulting in zero being stored.
>
> I've since changed it to be "auto e = ..." and it all works correctly now.
>
>
>
> Anyway I thought I'd share this just because one of the many times
> bearophile has talked about this as a potentially buggy situation, I was
> like "bah humbug"... and now I've actually been there!
>
> I still don't think I'm for changing the language though just because of
> potential annoyances in other places unsigned works (such as
> array.length) but at least I've actually felt the other side of the
> argument in real world code now.

This is exactly why many new languages only allow implicit integer 
conversions where the target type is strictly a >= type with the same 
sign, i.e. uint -> ulong, short -> int, and so on.

It is indeed very unfortunate that we have these dangerous implicit 
conversions in D. I would welcome a change to remove them (because it 
would likely catch real bugs in many cases).



... And, you know, many other changes to the language/compiler over the 
last couple of releases have broken plenty of my code. I wonder when 
we'll finally say "this is the D programming language, period". The 
current situation where some breaking changes are perfectly OK while 
others are not is kind of ridiculous.

I'm personally in favor of fixing some of the serious issues we have in 
the language once and for all and then *finally* stabilizing the 
language. It's ridiculous that we claim the language to be stable (or 
stabilizing) while we're still actively breaking real code to fix 
language issues. Fixing language issues is good and we should do it more 
so we can actually get to a point where we can call D stable. The 
current situation where some changes get blocked because the reviewer 
happens to be in a "D is stable" mood is -- sorry, but really -- stupid.

I used to even tell people "we're stabilizing D" when they ask why we 
don't fix some particular language design issue. I don't anymore, 
because I realized just how ridiculous this situation has gotten.

Well... end of rant.

-- 
Alex Rønne Petersen
alex at alexrp.com / alex at lycus.org
http://alexrp.com / http://lycus.org


More information about the Digitalmars-d mailing list