Clang emits memcpy for std::swap, which can introduce undefined behavior • Hacker News Board

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

#81

Post by astrange » Mon, Apr 25, 2016, 7:55 PM UTC

boulos wrote: post #6

majewsky wrote: post #4

Earlier quoted context omitted.

The second one sounds like big fun when you LD_PRELOAD a different memcpy (say, for debugging purposes) and spend hours and hours trying to figure out why it is not being called.

Yes, it's a nightmare, particularly on OS X with its funny loader semantics that make replacing malloc and free correctly very painful. For example, you can easily LD_PRELOAD your way out of malloc() but did you remember that asprintf also calls an allocation routine and won't use your new malloc? Enjoy.

malloc is set up to be specifically overridable so that guardmalloc(3)* will work. Are you saying asprintf doesn't work with guardmalloc?

* check it out, I used a man reference, am I a professional UNIX developer yet?

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

#82

Post by dtzWill » Mon, Apr 25, 2016, 8:11 PM UTC

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…

1) Challenges in understanding undefined behavior are exactly why tools like ubsan[1] exist. In a way they help /everyone/ understand when 'undefined' constructs are encountered, and having this emitted by the compilers responsible for translating your source code into binary code is the ideal place.

2) Compilers leveraging undefined behavior knowledge get a lot of hate for breaking this implicit contract defining what they "should" do as expected by programmers. Unfortunately these feelings are rather misguided, compilers are just doing what they can to produce the best code for you using the explicit contract that exists: the language specification(s). Are these specifications perfect? No, but they're what we have. If someone were to define a new language that actually captures the assumptions "real" programmers "expect" when they write code then compilers could choose to support it (and probably would!) and everyone would be happier. Until then this is a big case of "how come you're not doing that thing you never said you'd do and no one is willing to define properly?" which is a bit silly. Imagine you're a compiler developer: what assumptions CAN you make to satisfy everyone? In short, compiler developers aren't your enemy, they're just doing everything they can to produce the best code they can for you.

2a) Use of -f* is in a way used to define that a special variant of a language is desired, for example -fwrapv builds the code using an unnamed variant of C where signed integer overflow is well-defined.

[1] http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

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

#83

Post by lmm » Mon, Apr 25, 2016, 9:46 PM UTC

SFJulie wrote: post #79

lmm wrote: post #75

Earlier quoted context omitted.

Huh? Higher-level languages are much more portable than C - you only have to port the language runtime, and often someone's done that already. LLVM has a lot of different backends available.

hum.... well. If you imagine that they are 100% idempotent on every platform and 100% fully supported. It would work. But as I stated in my example python/Perl/C# and probably others are in the language support dropping either some platform or supporting only x% of the feature on some platform... I dare you to access you services using C#/mono on openBSD.

I'm running FreeBSD as it happens and C# works absolutely fine - I have even just downloaded random .net exes and run them and had them work.

If you had a race where you picked a random C program and a random python/perl/C# program off github/sourceforge/whatever and tried to run them on OpenBSD, I'm pretty sure 9/10 times the python/perl/C# would win.