From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81517 invoked by alias); 1 Nov 2017 14:25:42 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 80847 invoked by uid 89); 1 Nov 2017 14:25:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=HX-Gm-Message-State:sk:AJaThX7, life, perfect X-HELO: mail-qt0-f176.google.com Received: from mail-qt0-f176.google.com (HELO mail-qt0-f176.google.com) (209.85.216.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Nov 2017 14:25:31 +0000 Received: by mail-qt0-f176.google.com with SMTP id 31so2841382qtz.9 for ; Wed, 01 Nov 2017 07:25:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PZDJTC+qFhNpx2Rx51wFAHlzhkOrhWWvYuEktvxLX2s=; b=n+TNBHJOZkJsqUpgKFBYA9ytj1DEck+56lXEDoGbQAhs2B8PuGHiUGhPC9sJc/IfF8 PAIEWDvOciPBTuNqKxK5B8XpSomwcPOYOdruUkfMV0/8lp4jC9IAw3ybnukKlm2asdkN jJyDVhgbcYzifJBRSj/Od3L/Xz6Yp7LYaYxuOZ4jjPUQR/37JklnoCS2EgArpz4mEoX4 YUGsdHdre/vdXvt40r0koW2+EziZsfiiA1zg0wKeP7wO2EWX96TMPOzMXSIGaz5A/CHB RJeA5b1rN3/TDa0mpqHRnFKbAZlcBzhVB9IiM89cNuDlstKejVIIVYqLCEL5VKWs0jVO XO6Q== X-Gm-Message-State: AJaThX7R1q4oYwdxuwEbEvk0k4MU3NDb2a/kV26hhnVIyJ+dT2x/71QG IC7OVA/r+B60jjoGhD/ZEakhotGI5L/qiRiNIbMZzw== X-Google-Smtp-Source: ABhQp+Ql29SxxpaqMGHs4FJ+H6tyMtSjLy9QYRDWNxFpS8ihnfAgzQfEDpDLLfU1JjXpuK0NWTQwGync75d2DRmtYII= X-Received: by 10.200.15.136 with SMTP id b8mr90945qtk.64.1509546329295; Wed, 01 Nov 2017 07:25:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.35.85 with HTTP; Wed, 1 Nov 2017 07:25:28 -0700 (PDT) In-Reply-To: <515e5221f28f4df880916eaa1b25b7aa@SFHDAG5NODE3.st.com> References: <515e5221f28f4df880916eaa1b25b7aa@SFHDAG5NODE3.st.com> From: Csaba Raduly Date: Wed, 01 Nov 2017 14:25:00 -0000 Message-ID: Subject: Re: cygwin x86_64: mingw64-g++ 6.4.0 (both i686 and x86_64) issue (bug?) with reinterpret_cast To: cygwin list Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-11/txt/msg00007.txt.bz2 On Tue, Oct 31, 2017 at 11:00 AM, Paolo ZAMBOTTI wrote: > Hi Csaba, > Please don't top-post (at least in this mailing list). > Ok, then the issue are "my" lines of code and the error messages from g++ were not completely clear (and they was confusing me a little bit)... > But I'm still not sure the issue is not in Cygwin package. I mean, my test code was a very simplified (too much simplified) excerpt from squid source code and, there, the link with header file from cygwin package is more clear. > Then, let me post another test file where this link is more clear. > > Now the failure is as follow (g++ -std=gnu++11 -c -Wall -pedantic -Wextra test.cpp) > > In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/winbase.h:19:0, > from /usr/i686-w64-mingw32/sys-root/mingw/include/windows.h:70, > from test.cpp:1: > test.cpp:6:45: error: reinterpret_cast from integer to pointer > static constexpr HANDLE InvalidHandle = INVALID_HANDLE_VALUE; > ^ > > The issue is now within the macro definition of INVALID_HANDLE_VALUE in file handleapi.h (which could be, from i686-w64-mingw32, x86_64-w64-mingw32 or w32api) > > Now I'm wondering what is really wrong: > does the definition of INVALID_HANDLE_VALUE need to be rewritten in order to be compatible with the "static constexpr" line There's nothing wrong with INVALID_HANDLE_VALUE with regards to "static constexpr", although a constexpr expression cannot contain reinterpret_cast-s, and a C-style cast can resort to be a reinterpret_cast. But this doesn't seem to be the problem (there's a different error message for that). HANDLE is defined as a pointer: include/wtypesbase.h:52:typedef void *HANDLE; LONG_PTR is defined as an integer: basetsd.h:54:typedef long LONG_PTR,*PLONG_PTR; INVALID_HANDLE_VALUE is defined in handleapi.h:16 as #define INVALID_HANDLE_VALUE ((HANDLE) (LONG_PTR)-1) so you have a cast right there. Whenever you use INVALID_HANDLE_VALUE, the compiler sees a cast from long to void* I don't know how this could be fixed. You may want to ask on a mingw-specific mailing list. You could try adding -isystem /path/to/mingw/headers so mingw-gcc finds its headers that way (warnings tend to be suppressed for headers found in directories specified with -isystem rather than -i, although mingw-gcc's built-in headers should be treated the same way). (disclaimer: I havent tried this). > or > does "my" line of code has to be rewritten in order to be compatible with the INVALID_HANDLE_VALUE definition? > > In the latest case, any suggestion will be very welcome... > > Paolo. Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple