On Fri, Jan 5, 2018 at 6:37 PM, Martin Sebor <mse...@gmail.com> wrote: > On 01/05/2018 03:02 PM, Jakub Jelinek wrote: >> >> Hi! >> >> Apparently LLVM allows similar warning to -Wclass-memaccess (is it just >> similar or same?; if the latter, perhaps we should use the same option for >> that) to be disabled not just by casting the destination pointer to >> e.g. (char *) or some other pointer to non-class, but also to (void *), >> which is something that Qt uses or wants to use. > > Clang has an option/warning called -Wdynamic-class-memaccess. > It detects a limited subset of the problems -Wclass-memaccess > detects: AFAIK, just calling raw memory functions like memcpy > on objects of polymorphic types, which the standard says is > undefined. > > I didn't know about the Clang option when I wrote the GCC code. > Had I found out about it sooner I would have probably considered > splitting up -Wclass-memaccess and providing the same option as > Clang for compatibility, and another for the rest of the checks. > But there might still be time to split it up before the release > if that's important. > > Some Qt code apparently uses memcpy to copy polymorphic objects > but gets around the Clang warning by casting the pointers to > void*, which doesn't suppress the GCC warning. I had considered > allowing the void* cast as a possible suppression mechanism but > ultimately decided against it. IIRC, partly because it would > have complicated the implementation and partly because I wasn't > convinced that it was a good idea (and I also didn't know about > the Clang escape hatch). > >> The problem is that the warning is diagnosed too late and whether we had >> explicit or implicit conversion to void * is lost at that point. >> >> This patch moves the warning tiny bit earlier (from build_cxx_call to the >> caller) where we still have information about the original parsed >> arguments before conversions to the builtin argument types.
OK. > I'm still not convinced that letting programs get away with > byte-wise copying polymorphic objects is a good thing, but I > agree that supporting the void* cast suppression will be useful > for portability with Clang (presumably both C-style cast and > C++-style static_cast work). IMO It's good to have a way to suppress any warning by being more verbose. Warnings are to highlight inadventent mistakes, not deliberate ones. > If we want to make it a feature then we should document it in > the manual. Otherwise, if it's supposed to be a back door for > poorly written code, then I think it would be helpful to mention > it in comments in the implementation and above the assertion in > the test. I don't like undocumented back doors so I'm leaning > toward documenting it in the manual. I'm happy to add some > text to the manual if/when this is approved and decided. I agree that this should be documented. Jason
