Live data from Hacker News

Clang vs. Clang

blog.cr.yp.to

401–405 of 405 posts

Re: Clang vs. Clang

#402

Earlier quoted context omitted.

Yes, this is an example of UB leaving memory in a bad state. If you want an example of something that is not UB leaving memory in a bad state, here is some Go code: global := 7; func main () { go func() { global = 1000000; }() go func() { global = 10 }() fmt.Printf("gloabl is now %d") } The two concurrent writes may partially overlap, and global may have a value that is neither 7 nor 10 nor 1000000. The program's mem…

The C standard definitely has opinions on races

Please share a link.

Re: Clang vs. Clang

#404
post #95

Earlier quoted context omitted.

I think this is actually a mistake by the author since the rant is mostly focused on implementation defined behavior, not undefined. The examples they give are all perfectly valid code. The specific bugs they're talking about seem to be compiler optimizations that replace bit twiddling arithmetic into branches, which isn't a safe optimization if the bit twiddling happens in a cryptographic context because it opens th…

The blog post does, at the very end, mention the thing you should actually do . You need a language where you can express what you actually meant, which in this case is "Perform this constant time operation". Having expressed what you meant, now everybody between you and the hardware can co-operate to potentially deliver that. So long as you write C (or C++) you're ruined, you cannot express what you meant, you are s…

not only does it mention that, the author also implemented that language, jasmin, with some collaborators. he does mention that, but he doesn't mention that he'd already done it previously, the unreleased qhasm

Re: Clang vs. Clang

#405
post #95

Earlier quoted context omitted.

I think this is actually a mistake by the author since the rant is mostly focused on implementation defined behavior, not undefined. The examples they give are all perfectly valid code. The specific bugs they're talking about seem to be compiler optimizations that replace bit twiddling arithmetic into branches, which isn't a safe optimization if the bit twiddling happens in a cryptographic context because it opens th…

The blog post does, at the very end, mention the thing you should actually do . You need a language where you can express what you actually meant, which in this case is "Perform this constant time operation". Having expressed what you meant, now everybody between you and the hardware can co-operate to potentially deliver that. So long as you write C (or C++) you're ruined, you cannot express what you meant, you are s…

> what you actually meant, which in this case is "Perform this constant time operation".

This notion is not expressible in most (or almost all) high-level programming languages. Or, to put it another way: If you wrote C or C++ you never mean to say "perform this guaranteed-constant-time CPU operation" (ignoring asm instructions and hardware-aware builtins).

Post reply on HN