I tested these _out of box_ cases: No patch: GCC: silent | Clang: 32bit silent, 64bit error
Cast to "PUWSTR_C": GCC: silent | Clang: silent Union cast: GCC: silent | Clang: silent If you want to use Union cast You should create fix because I have no idea about MinGW-w64 coding standards in case like this. Testing this is very tricky since I could reproduce it only when building 64bit libc++ but to get to this stage enormous amount of hacks have been created (workaround missing mingw-w64 defines, wrong code for mingw, etc.) Basically both compilers tell it comes from "#include<Windows.h>" from few cpp files: |In file included from D:/projekty/msys2/MINGW-packages/mingw-w64-clang/src/llvm-3.9.0.src/projects/libcxx/src/chrono.cpp:40: In file included from D:\projekty\msys2\clang\msys64\mingw64\x86_64-w64-mingw32\include\windows.h:114: D:\projekty\msys2\clang\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:121:37: error: cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *') with an rvalue of type 'const wchar_t *' ... | Regards, Mateusz ------ Original Message ------ Subject: Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t * Date: Fri, 7 Apr 2017 10:00:26 -0700 To: Mingw-w64-public From: David Grayson > I did read the top two answers in the link that Norbert posted: > > http://stackoverflow.com/questions/11373203/accessing-inactive-union-member-and-undefined-behavior > > The first answer (from ecatmur) indicates that this kind of conversion with > a union would be undefined behavior in C++, but not C. I'm not sure what > else to read, except the latest C++ standard, which was quoted heavily in > the answer. > > The second answer (from Bo Persson) provides a useful link to the GCC > documentation which makes me think that GCC provides additional guarantees > beyond what the standard says, and so this kind of conversion would > actually be safe, in both C and C++. Since GCC behaves that way, clang > probably would too. So yeah, the union conversion is probably fine because > of the design of the compilers we care about. > > I think casting would work too. When LH_Mouse's reasoned about why the > warnings would not be a problem, Kai said: "Each compiler has its own > variants for this. But well, why we should rely on such things." Are you > more OK with relying on the details of compiler behavior for union > conversions than the details of compiler behavior for warnings? > > --David > > On Fri, Apr 7, 2017 at 9:31 AM, Kai Tietz <ktiet...@googlemail.com> wrote: > >> 2017-04-07 17:21 GMT+02:00 David Grayson <davidegray...@gmail.com>: >>>> type1 *foo(const type1 *my_const_ptr) >>>> { >>>> union { >>>> type1 *t1; >>>> const type1 *ct1; >>>> } v; >>>> v.ct1 = my_const_ptr; >>>> return v.t1; >>>> } >>> Yes, that is sad, and it seems like just a matter of time before a C++ >>> compiler looks at the code above and reasons that the write to ct1 can be >>> optimized away because there is no code that ever reads from ct1. Thus >> the >>> read from t1 will be recognized as undefined behavior (probably called a >>> poison value in LLVM) and anything could happen. >> LOL ... if a compiler modifies a technical valid language construct, >> and produces by this optimization something it needs to warn about, >> then the compiler has a bug. And well, you should be sad to use such >> a compiler, as it is broken in many aspects. >> >> >>> What was the problem with Mateusz's patch? I think people are implying >> it >>> results in compiler warnings, but I thought casting a pointer to a >> pointer >>> usually doesn't give any warnings. >> The problem is that you seems to see an UB, where actually none is. >> Please try read a bit about C++, compatibility to C, and what, and how >> a union on pointer types are treated in a union (especially the part >> about integer scalars & pointers). >> >> ~Kai >> >> PS: As you already recognized, yes the issue is to avoid warnings OP >> doesn't expect them. >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
