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

Dimitry Andric via cfe-commits cfe-commits at lists.llvm.org
Fri Jan 13 04:40:16 PST 2017


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?

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170113/f4b4cb18/attachment-0001.sig>


More information about the cfe-commits mailing list