r284890 - DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.

[Richard Smith via cfe-commits]

On 13 Jan 2017 4:40 am, "Dimitry Andric via cfe-commits" <
cfe-commits at lists.llvm.org> wrote:

On 22 Oct 2016, at 00:00, Richard Smith via cfe-commits <
cfe-commits at lists.llvm.org> wrote:
>
> Author: rsmith
> Date: Fri Oct 21 17:00:42 2016
> New Revision: 284890
>
> URL: http://llvm.org/viewvc/llvm-project?rev=284890&view=rev
> Log:
> DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type'
rules.
> This has two significant effects:
>
> 1) Direct relational comparisons between null pointer constants (0 and
nullopt)
>   and pointers are now ill-formed. This was always the case for C, and it
>   appears that C++ only ever permitted by accident. For instance, cases
like
>     nullptr < &a
>   are now rejected.
>
> 2) Comparisons and conditional operators between differently-cv-qualified
>   pointer types now work, and produce a composite type that both source
>   pointer types can convert to (when possible). For instance, comparison
>   between 'int **' and 'const int **' is now valid, and uses an
intermediate
>   type of 'const int *const *'.
>
> Clang previously supported #2 as an extension.
>
> We do not accept the cases in #1 as an extension. I've tested a fair
amount of
> code to check that this doesn't break it, but if it turns out that
someone is
> relying on this, we can easily add it back as an extension.
>
> This is a re-commit of r284800.

Hi Richard,

This indeed leads to a bit of breakage when we compile lots of FreeBSD
ports, for example openjdk7 (https://bugs.freebsd.org/216016), ptlib (
https://bugs.freebsd.org/216019), spidermonkey24 (https://bugs.freebsd.org/
216010), and webkit-qt4 (https://bugs.freebsd.org/216015) will now produce
errors similar to:

vidinput_v4l.cxx:981:23: error: ordered comparison between pointer and zero
('BYTE *' (aka 'unsigned char *') and 'int')
      if (videoBuffer < 0) {
          ~~~~~~~~~~~ ^ ~

There will probably be more of these.  Is it the intent of this change that
such software must now be patched up?


That is the intent; such code is not valid c++ any more per the latest
defect resolutions (and is not valid C). Depending on the level of pain, we
could allow these comparisons as an extension, so I would welcome your
input here. However (for instance) the example above looks like a bug.

-Dimitry


_______________________________________________
cfe-commits mailing list
cfe-commits at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170113/179f29c2/attachment-0001.html>