Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clang emits memcpy for std::swap, which can introduce undefined behavior

llvm.org

Post reply on HN
Print view View original

61–70 of 83 posts

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#61

Post by haberman »

Joky wrote: post #59
haberman wrote: post #58

Earlier quoted context omitted.

I can't see an argument here for why the standard should be changed. memcpy() does one thing and memmove() does another. Changing the standard so they are the same just because memcpy() gets misused in real-world programs doesn't make sense to me. If people misuse memcpy(), then have a compiler flag akin to -fstrict-aliasing where memcpy() gets rewritten to memmove() unless people compile with -fstrict-memcpy. That s…

It is not about making memcpy behave the same as memmove: in this case the difference would still be between exact identity (src == dest) and partial overlap.

I see, thanks for clarifying. I agree there could be reason to consider a change in that case.

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#62

Post by archgoon »

electrograv wrote: post #28
haberman wrote: post #10

Given how aggressively compilers (including Clang) are exploiting undefined behavior these days, it is surprising to see Clang developers (I presume) on the bug being so blasé about introducing undefined behavior themselves.

> it is surprising to see Clang developers (I presume) on the bug being so blasé about introducing undefined behavior themselves. I have suddenly lost a great deal of respect and confidence for LLVM/Clang after reading this bug thread; I value software reliability above all else, and being able to write reliable software without the compiler negating that effort. It seems I can no longer be assured this is even a pri…

> All the more reason to switch to Rust I suppose.

Rust is backed by llvm.

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#63

Post by lomnakkus »

archgoon wrote: post #62
electrograv wrote: post #28

Earlier quoted context omitted.

> it is surprising to see Clang developers (I presume) on the bug being so blasé about introducing undefined behavior themselves. I have suddenly lost a great deal of respect and confidence for LLVM/Clang after reading this bug thread; I value software reliability above all else, and being able to write reliable software without the compiler negating that effort. It seems I can no longer be assured this is even a pri…

> All the more reason to switch to Rust I suppose. Rust is backed by llvm.

Not particularly sure how that's particularly relevant here. This is an issue with Clang, AFAIUI.

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#64

Post by archgoon »

lomnakkus wrote: post #63
archgoon wrote: post #62

Earlier quoted context omitted.

> All the more reason to switch to Rust I suppose. Rust is backed by llvm.

Not particularly sure how that's particularly relevant here. This is an issue with Clang, AFAIUI.

Well, electrograv was not distinguishing between the llvm project and the clang project. So it seemed reasonable to point out that rust was using llvm.

> I have suddenly lost a great deal of respect and confidence for _LLVM_/Clang after reading this bug thread;

However, do you believe that there is little overlap between llvm developers and clang developers?

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#65

Post by ploxiln »

colin_mccabe wrote: post #60
chandlerc1024 wrote: post #54

Earlier quoted context omitted.

That comment was actually a considered comment: when we look at what warnings we should produce, we consider cases where everyone has written code a particular way and the fact that it isn't defined is actually a language bug. We (the Clang community members, and I suspect the GCC community members as well) have also worked to change language standards to provide guarantees relied on consistently and where the lack o…

LLVM is a very impressive compiler. I'm really impressed with the warning messages it's able to produce (especially compared with what was available even 2 or 3 years ago). What is more frustrating about modern compilers (and this is not limited to LLVM) is the desire to squeeze out a tiny bit more performance by exploiting undefined behavior. I'm thinking of things like eliminating calls to memset that "don't seem t…

You may be thinking of "implementation-defined behavior" which is not exactly the same as "undefined behavior".

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#66

Post by jeffdavis »

slededit wrote: post #41
kazinator wrote: post #31

Earlier quoted context omitted.

Rather, they are getting zealous in eliminating code because of the assumption that there is no undefined behavior . The scope of what undefined behaviors do this is increasing and that breaks programs that make some assumptions on traditional compiler behavior, or that have hidden bugs. I believe that C should have safer semantics, plus standard-defined modes of operation which restore the unsafe semantics selective…

I agree you should be able to opt-in to a safety level. For example most programmers do expect signed integer overflows to follow 2s compliment behavior - regardless of what the standard says. There really seems to be a large disconnect between the tool writers and the users of said tools. I've had countless discussions with compiler writers where we've essentially talked passed each other. The compiler writer arguin…

Keep in mind that the compiler doesn't always know whether code is undefined or not. Is x+y at risk of overflow? Maybe, depending on some logic in a separate compilation unit.

So what your asking is to define behavior for all code, such that the compiler can prove locally that's it's well-defined. That's not a crazy idea, and a lot of languages do that.

But C counts itself as special, for better or worse.

I think we really just need more alternatives. There's C++, Rust, Ada, and not much else. I am very hopeful about rust.

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#67

Post by astrange »

xorblurb wrote: post #51
chandlerc1024 wrote: post #34

Earlier quoted context omitted.

Hi, LLVM and Clang developer here. I don't see anyone being blasé about this. The issue comes down to something really simple: - The compiler can emit substantially simpler code if it has a guarantee from the platform's implementation of memcpy. - The compiler authors thought they had such a guarantee and so chose to leverage it. Now, maybe they don't have that guarantee on all platforms. If that's the case, its flat…

Can't you see the pattern here? Even LLVM devs are incapable of doing what they are requiring from random regular developers. If that does not motivate to address that kind of craziness more in depth in a systematic way to restore safety and defense in depth, I don't know what will. - Programmers can and do emit substantially simpler code if they have a guarantee from the platform's implementation of . - Programmers…

> It's actually reasonable to have a platform that e.g. gives you 2's complement arithmetic or defines the result of shifts, or allows unaligned access, because mainstream computer hardware does provide those guarantee.

ARM, PPC, and x86 all define the results of some shifts differently (for shift amounts >32UL) and behave differently with unaligned pointers (only x86 tends to accept them). Which mainstream hardware are you using?

Adding magical nice semantics to your language is another way to hide bugs in your program. Try building with ubsan and doing runtime testing instead.

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#68

Post by anon1385 »

chandlerc1024 wrote: post #54
haberman wrote: post #48

Earlier quoted context omitted.

Hi Chandler, I should have clarified that the comments I was referring to were on this bug: https://llvm.org/bugs/show_bug.cgi?id=11763 I was surprised to see: "I don't think it's really worth warning about, considering I don't know of any real-world implementation where it doesn't work." That sounds a lot like someone knowingly writing UB in a C program because no compiler they know of breaks the intended behavior.…

That comment was actually a considered comment: when we look at what warnings we should produce, we consider cases where everyone has written code a particular way and the fact that it isn't defined is actually a language bug. We (the Clang community members, and I suspect the GCC community members as well) have also worked to change language standards to provide guarantees relied on consistently and where the lack o…

> I don't actually expect glibc to break this in the foreseeable future

Would you have said this if Ulrich Drepper was still in charge of glibc? Under his ownership glibc broke all sorts of things that happened to rely on memcpy behaving like memmove[1]. I'm not sure he would have been any more accommodating of non-conforming compilers than of non-conforming flash implementations.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=12518

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#69

Post by anon1385 »

haberman wrote: post #48
chandlerc1024 wrote: post #34

Earlier quoted context omitted.

Hi, LLVM and Clang developer here. I don't see anyone being blasé about this. The issue comes down to something really simple: - The compiler can emit substantially simpler code if it has a guarantee from the platform's implementation of memcpy. - The compiler authors thought they had such a guarantee and so chose to leverage it. Now, maybe they don't have that guarantee on all platforms. If that's the case, its flat…

Hi Chandler, I should have clarified that the comments I was referring to were on this bug: https://llvm.org/bugs/show_bug.cgi?id=11763 I was surprised to see: "I don't think it's really worth warning about, considering I don't know of any real-world implementation where it doesn't work." That sounds a lot like someone knowingly writing UB in a C program because no compiler they know of breaks the intended behavior.…

>btw. I'm pretty sure I heard that glibc broke this behavior sometime recently.

You are perhaps thinking of this: https://sourceware.org/bugzilla/show_bug.cgi?id=12518

I'm not sure if that change broke glibc memcpy for identical arguments or just ones that were different but overlapped.

This quote suggests that Drepper wouldn't have had any problem breaking things that passed identical arguments to memcpy:

>The existence of code written by people who should never have been allowed to touch a keyboard cannot be allowed to prevent a correct implementation.

Re: Clang emits memcpy for std::swap, which can introduce undefined behavior

#70

Post by lmm »

SFJulie wrote: post #45

Reading most thread of llvm bugs so far about there "undefined behaviours" I see a pattern. Llvm goal is performance over correction. stop. If old code breaks, it is you played with fire, correct your code to eliminate these undefined behaviours. Stop. We made wonderful coloured warning to help you. Full Stop. Well on one hand I get the point, people played with fire. Code should be "correct" by standards that are em…

Much of the transition has already happened - most applications have already moved on from C to safer languages. What's coming is either the replacement of C libraries (Rust, very careful C rewrites), or perhaps bypassing them entirely (OCaml unikernel work).

I would fear more for proprietary systems. Open source is relatively innovative and adaptable.

Post reply on HN