Spot the bug: wchar_t buf[123]; swprintf(buf, sizeof buf, "%s/%d", str, num);
From a usable security standpoint, an API that /looks just like/ one where sizeof works, but where it's wrong, is utterly awful.
-
-
Functions like swprintf probably should have taken a buffer size, not a [wchar_t/whatever] count.
-
That makes it harder to access the last-written location.
-
I don't follow. The return value would still be a wchar_t count.
-
Er, in that case it means I can't subtract it from the buffer size.
-
If I were to change something here, it would be sizeof, which does the "wrong" thing for pointers too.
-
You can differ all you like philosophically but it doesn't mitigate danger of interfaces that look like they take a size
-
How many people even know if swprintf takes a size or wchar_t count without looking it up?
-
I posit that if there's a choice, "count" is always the right answer. Other langs don't even have access to byte-size.
- 2 more replies
New conversation -
-
-
it also seems like something ripe for static analysis. Wonder if compiler makers will do stricter warns
-
_FORTIFY_SOURCE should be able to catch it in most cases.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.