[Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

[Jean-Michaël Celerier]

>   For an unsigned {over,under}flow, it can't, since
there's nothing to sanitize, all behavior is well-defined, sane or
not.

-fsanitize=undefined also detects unsigned overflow even though the
behaviour is technically defined because it is such a large source of bugs
(I mean, they write the compiler; they can make it pop out butterflies in
A4 paper upon integer increment if they want).

See https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html



On Wed, Dec 5, 2018 at 8:24 PM Ville Voutilainen <
ville.voutilainen at gmail.com> wrote:

> On Wed, 5 Dec 2018 at 21:11, Jean-Michaël Celerier
> <jeanmichael.celerier at gmail.com> wrote:
> >
> > On Tue, Dec 4, 2018 at 8:45 PM Thiago Macieira <
> thiago.macieira at intel.com> wrote:
> >>
> >> On Tuesday, 4 December 2018 10:43:31 PST Bernhard Lindner wrote:
> >> > Then let me rephrase my opionen: What every you plan to change
> regarding
> >> > size types in Qt6... do it the standard (C++20?) way.
> >>
> >> We're doing it the way the committee says it should have done in the
> first
> >> place, not the way it has done: signed.
> >>
> >
> > Thanks, underflowing operations on std::containers's size_t have been an
> unending source of bugs in the projects I work on.
> > (thankfully nowadays clang can check for it with -fsanitize=undefined).
>
> That is indeed one argument for a signed type, as opposed to an
> unsigned type. For a signed {over,under}flow, a sanitizer can detect
> your mistakes. For an unsigned {over,under}flow, it can't, since
> there's nothing to sanitize, all behavior is well-defined, sane or
> not.
>
> For historical perspective, John Lakos makes this argument (and mostly
> every other argument speaking in favor of a signed
> type and against an unsigned type) in his very old book, "Large-Scale
> C++ Software Design". To repeat, the reason
> why the committee keeps insisting span::size() returning a size_type
> (which is practically a size_t) is not because we think
> it's great, we (well, in the most recent discussion, a consensus
> majority of us) just think that span should not be given a
> magical exception when everything else returns an unsigned type.
>
> A significant part of the overall concern, at least as far as stdlib
> vendors goes, is ABI. We do have the opportunity at Qt 5->6 to break
> ABI.
> We *are* going to break ABI just by the nature of changing what the
> library is to link against, so we have the opportunity to do useful
> ABI breaks.
> In that sense, we have far less stringent compatibility
> requirements/expectations/wishes/aspirations than a stdlib
> implementation like
> libstdc++ (or to historically less extent, but changing over time,
> libc++, and same for msvclib) has.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181205/6fcd49c2/attachment.html>