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

How to zero a buffer

daemonology.net

Post reply on HN
Print view View original

211–216 of 216 posts

Re: How to zero a buffer

#211

Post by exDM69 »

TheLoneWolfling wrote: post #207
exDM69 wrote: post #177

Earlier quoted context omitted.

foo->bar->baz[i].oof = foo->bar->baz[i].durb + meep; This is fine, no need to "optimize" anything. This kind of common subexpression elimination should be done by any modern compiler (for any language!) and the algorithm behind it is taught in university classes too. Most of the time it's safe to use -O3. If you're doing numerical code with floating points -ffast-math is also pretty safe if your code is correct (ie.…

This shouldn't need to be said, but don't use -ffast-math if you want reproducibility. Unfortunately, the times when you most want reproducibility tend to be the same sorts of number-crunching where -ffast-math would be most useful.

> Unfortunately, the times when you most want reproducibility tend to be the same sorts of number-crunching where -ffast-math would be most useful.

Thanks for the clarification. The obvious caveats of -ffast-math are well documented and most applications shouldn't use that flag.

There are exceptions to this however, I tend to work on such problems. For example, game physics, 3d graphics and some scientific algorithms that have built-in numerical inaccuracy (so -ffast-math doesn't help but doesn't hurt either) but high perf requirements. I also tend to have extensive testing for the most crucial parts of my programs that should catch any problems with this (but many people don't do this with game physics, etc code).

Thankfully, -ffast-math is easy to disable if you start suspecting problems that are caused by that flag.

Re: How to zero a buffer

#212

Post by exDM69 »

PhasmaFelis wrote: post #137
bunderbunder wrote: post #65

Earlier quoted context omitted.

I'm gonna go ahead and say it: Perhaps in retrospect C is an inappropriate choice of language for these kinds of applications. This "Performance at all costs, including safety and predictability" thing may be appropriate in video games, but for security-critical applications that philosophy is downright negligent.

C/C++ are like Formula 1 racing cars: indispensable if you need to go really, really fast; wildly impractical in all other situations.

> C/C++ are like Formula 1 racing cars ...

I can't agree with this comparison at all. It may be true if speed is what you want but that's not the only reason.

C (and to a lesser extent, C++) are indispensable in lots of situations where you're working close to the metal. There are very few viable alternatives when working with kernel space code, micro controllers or embedded applications as well as crypto primitives.

Rust is perhaps the only language that can be used instead of C and C++ in these applications.

I'd liken C more to a heavy duty vehicle, something that most people never need but there's no replacement for the tasks it is intended for.

Re: How to zero a buffer

#213

Post by TheLoneWolfling »

exDM69 wrote: post #211
TheLoneWolfling wrote: post #207

Earlier quoted context omitted.

This shouldn't need to be said, but don't use -ffast-math if you want reproducibility. Unfortunately, the times when you most want reproducibility tend to be the same sorts of number-crunching where -ffast-math would be most useful.

> Unfortunately, the times when you most want reproducibility tend to be the same sorts of number-crunching where -ffast-math would be most useful. Thanks for the clarification. The obvious caveats of -ffast-math are well documented and most applications shouldn't use that flag. There are exceptions to this however, I tend to work on such problems. For example, game physics, 3d graphics and some scientific algorithms…

I'd diagree, Game physics and scientific algorithms are often precisely where you want reproducible results.

Game physics because of lockstep networking and replays, scientific algorithms because... well, you want your results to be reproducible. Scientific method and all that.

Often times you don't mind if it isn't accurate, but that isn't the same thing as precision. You want it to be precise, i.e. reproducible.

Yes, there are cases

Re: How to zero a buffer

#214

Post by MichaelMoser123 »

dllthomas wrote: post #210
MichaelMoser123 wrote: post #209

You can have a function that wrapps memset with zero argument this wrapper should be in a different shared library, this way the compiler will not follow it; wait, that's exactly what memset_s is,

Not exactly. There's no reason memset_s can't be understood by the compiler, inlined, and optimized, so long as those bits still get zeroed. That's not the case for any of the other approaches.

the compiler should not make any assumption about what memset_s is doing (same goes for user defined memset wrapper function in different shared library - the implementation of that function is not known at compile or link time); if it can't make such assumption then it can't optimize the call out.

Re: How to zero a buffer

#215

Post by dllthomas »

MichaelMoser123 wrote: post #214
dllthomas wrote: post #210

Earlier quoted context omitted.

Not exactly. There's no reason memset_s can't be understood by the compiler, inlined, and optimized, so long as those bits still get zeroed. That's not the case for any of the other approaches.

the compiler should not make any assumption about what memset_s is doing (same goes for user defined memset wrapper function in different shared library - the implementation of that function is not known at compile or link time); if it can't make such assumption then it can't optimize the call out.

I think you misunderstand me. There is no guarantee that there will be no optimization of or around memset_s (at least, not provided by the standard), and we don't want one. What the standard has done is assured us that it will not be optimized away - that the effect of zeroing that memory will be treated as visible even if the memory is otherwise dead. Allowing the compiler to optimize without changing semantics is desirable, and is permitted by the standard but prevented by the attempts to erect artificial walls through linking (and also by the volatile function pointer in the article), so memset_s - in addition to being clearer - is a technically superior solution.

Re: How to zero a buffer

#216

Post by swift »

tedunangst wrote: post #78
swift wrote: post #73

Earlier quoted context omitted.

Many languages zero every allocation unless they can prove that you immediately write over that memory without reading it.

Which does nothing for memory which has been freed but not reallocated.

That's a great point; should've thought through that post a little better. Thanks.
Post reply on HN