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

Things to commit just before leaving your job

gist.github.com

Post reply on HN
Print view View original

11–20 of 165 posts

Re: Things to commit just before leaving your job

#12

Post by Kenji »

lfam wrote: post #8
Kenji wrote: post #3

#define volatile // this one is cool Oh wow. This literally sent a shiver down my spine. Imagine debugging that. Also love the randmoness based ones!

Will you explain what this would do?

Of course :)

Basically this removes the volatile keyword from your code and replaces it with... nothing.

If a variable is declared volatile, it disables compiler optimizations and signals the compiler that this variable can be modified at any time (e.g. by hardware or other threads). Omitting volatile can lead to nasty concurrency bugs (e.g. if the optimizer optimizes spin locks away). In the worst case, such bugs are extremely hard to reproduce (and thus debug) but lead to deadlocks and/or crashes in case they do occur.

Re: Things to commit just before leaving your job

#13

Post by chedabob »

masklinn wrote: post #9
kevindeasis wrote: post #5

If only we can get a rosettacode version of this in all languages. I bet trolls will coming out left and right. It would be pure evil.

Most languages don't have a purely textual and completely unsafe preprocessor running during the compilation process, so it would be quite hard.

You could do some real evil stuff with reflection though, such as messing with Java's IntegerCache: http://codegolf.stackexchange.com/a/28818

Re: Things to commit just before leaving your job

#17

Post by cgranade »

Kenji wrote: post #12
lfam wrote: post #8

Earlier quoted context omitted.

Will you explain what this would do?

Of course :) Basically this removes the volatile keyword from your code and replaces it with... nothing. If a variable is declared volatile, it disables compiler optimizations and signals the compiler that this variable can be modified at any time (e.g. by hardware or other threads). Omitting volatile can lead to nasty concurrency bugs (e.g. if the optimizer optimizes spin locks away). In the worst case, such bugs ar…

That would also break the trick of declaring something `const volatile`. While that seems like a contradiction, I've heard of it being used to force the compiler to include a symbol in the final object file. In particular, I've seen it used to make a poor-man's plugin architecture.

Re: Things to commit just before leaving your job

#18

Post by masklinn »

Kenji wrote: post #12
lfam wrote: post #8

Earlier quoted context omitted.

Will you explain what this would do?

Of course :) Basically this removes the volatile keyword from your code and replaces it with... nothing. If a variable is declared volatile, it disables compiler optimizations and signals the compiler that this variable can be modified at any time (e.g. by hardware or other threads). Omitting volatile can lead to nasty concurrency bugs (e.g. if the optimizer optimizes spin locks away). In the worst case, such bugs ar…

> Omitting volatile can lead to nasty concurrency bugs (e.g. if the optimizer optimizes spin locks away). In the worst case, such bugs are extremely hard to reproduce (and thus debug) but lead to deadlocks and/or crashes in case they do occur.

In C and C++, volatile is not intended and must not be used for synchronisation primitives, it is not a memory fence (so it does not force cache coherency and does not prevent operations reordering) and operations on volatile variables are not atomic. Its primary use case is memory-mapped IO (with a sub-use case of preventing eliding memory operations affected by inline assembly). If a lock is broken because `volatile` is disabled, it's probably incorrect in the first place.

All `volatile` does[0] is forbid elision of loads and stores.

[0] again in C or C++, Java and C# have completely different semantics

Re: Things to commit just before leaving your job

#19

Post by praseodym »

mavelikara wrote: post #10
yarper wrote: post #2

We've got a guy in the office that merges the past over the present all the time. He's not quitting but I imagine if you were to try to break things this would be a good way to do it.

I am curious - wouldn't your Version Control system catch this and warn him that "file xyz has changed since you last checked it out, ..." etc?

DVCS systems like Git and Mercurial will require you to merge, but if you use a GUI VCS frontend it's really easy to choose the "use my local stuff" button. Been there with some university projects groups. (These people also liked the "force push" method of merging.)

Re: Things to commit just before leaving your job

#20

Post by gberger »

hellofunk wrote: post #15

Perhaps the most enlightening (and actually useful) purpose of this file is to dramatize the glaring weakness in the c/c++ macro system. A proper macro system would not make it so easy to do this, shall we say, "evil", stuff :)

Ruby too:

    class Fixnum
      def +(other)
        self - other
      end
    end

    10 + 3 
    >>> 7
Post reply on HN