• Ithryn (unregistered) in reply to C-Octothorpe

    Yes, because of string interning

  • Arkady (unregistered)

    First one, nicked from xkcd:

    #define rand rand_bomb
    
    int rand_bomb()
    {
         return 4; //Chosen by a fair die. Guaranteed to be random.
    }
    

    More subtle - go into the cmath or math.h header file, and reduce the definition of RAND_MAX by 1. This will produce very rare errors that probably won't have any error checking.

  • A Gould (unregistered) in reply to alegr
    alegr:
    Rosuav:
    Turning all privates public doesn't actually do much.
    Other than charges of indecent exposure, that is.

    All in favor of there being a compiler error saying "Warning: indecent exposure detected"?

  • Pyrexkidd (unregistered)
    Comment held for moderation.
  • frits (cs) in reply to C-Octothorpe
    C-Octothorpe:
    lax:
    C#:
    static SomeCtor()
    {
      typeof(string).GetField("Empty").SetValue(null, " ");
    }
    //Sets string.Empty to a space character

    __ Note from Alex: I just tested, and this actually works!

    You know, I've always wondered why that field was static... Is it because of string interning?

    (honest question)

    Probably because it's not a property of a given instance of string. The use of String.Empty is encouraged because of string interning, though.

  • jasmine2501 (cs) in reply to GettinSadda
    I actually added a bomb in some code I sent to a previous employer (in a different country), but I told them I had inserted the bomb, and would forward the source, without bomb, once payment cleared. This could be re-purposed.

    That could even work as a bluff... most customers wouldn't know you were bluffing, particularly if they don't have the source.

  • Austin (unregistered) in reply to Cipri
    Cipri:
    I'd have to go with making a cronjob running
    dd if=/dev/urandom of=/dev/kmem bs=1 count=1 seek=$RANDOM
    

    Replace a random bit of kernel memory with a random value.

    That's just cruel...

  • C-Octothorpe (unregistered) in reply to frits
    Comment held for moderation.
  • kastein (unregistered) in reply to Capt. Obvious
    Capt. Obvious:
    Wim:
    The use of rand() does not give non-deterministive behavior. The example will always crash at the same point in the program (assuming the rest is deterministic)

    My idea would be (for C):

    #include <stdlib.h>
    
    static inline void *
    malloc_bomb(size_t size)
    {
        if (size>8) size-=8;
        return malloc(size);
    }
    
    #define malloc malloc_bomb //#defined moved as indicated by many postings
    

    Clever error. But depending on the internal procedures at the company

    size+=8;
    may be a worse condition. (Magic number 8 requires tuning.) The free should be based on the objects theoretical size, not the malloc, resulting in a slow leak. Especially brutal because each component group can blame another, and be convinced that they aren't causing the leak.
    what universe are you from in which you pass a size to the free() function in addition to the base address of the object/allocation which you wish to free?

    Speaking of which, a "one in ten thousand calls to free() will result in a double free" bomb would be pretty nifty. If they get lucky, they might even dodge the bullet on the double free, making it even harder to track down.

  • Anonymous (unregistered)

    Here's a few I just thought up, while reading some of the submissions. Just put this in some header everyone includes. It's C++ only though:

    #define virtual /* Nothing */
    

    For those who don't know C++ -- this will disable polymorphism in many useful situations. Of course, it breaks code which uses pure virtual. But if you provide virtual functions with implementations in the base class, you can wreak all kinds of havoc with this #define before that class.

    The other one is this (I didn't define all of the attendant operators and types, I just wanted to give the gist):

    class LeakyString
    {
        private:
           std::string *str;
    
        public:
            LeakyString( const char *const s )
                    : str( new std::string( s ) ) {}
    
            LeakyString( const LeakyString © )
                    : str( new std::string( *copy.str ) ) {}
    
            LeakyString &
            operator= ( const LeakyString &rhs )
            {
                LeakyString tmp( rhs );
                std::swap( this->str, tmp.str );
                delete tmp.str; // Don't leak all the time
            }
    
            ~LeakyString() {} // Just leak our string sometimes
    
        // Assume the necessary internals to emulate a string
    };
    
    // Try to get everyone using our leaky implementation,
    // but we'll possibly wreak some compiler havoc if 
    // string is a variable name or something...
    #define LeakyString string
    

    As one last alternative, the above LeakyString could be implemented as a template class called "basic_string" in a private file called "string" in your project's library, and you could alter your makefiles to pick up the leaky string header instead of the standard library header.

    In essence -- a string which leaks, on purpose. If you go the route of faking out the compiler, you can really cause developers to wonder what the heck is going on.

    Regarding those who are mucking with the definition of NULL... C++0x has "nullptr" coming out -- a faulty definition of this could be provided and #defined... Plenty of opportunities for evil, especially since some projects already have custom "nullptr.h" headers which emulate this coming feature.... I've already written one for a few projects I work on... Should I ever become truly digruntled... {Insert evil grin here}

    captcha: nulla Very appropriate!

  • Mike (unregistered)

    C:>d: D:>cd i386 D:\I386>setup

    worst code-bomb EVAR

  • Artemus Harper (unregistered)
    Comment held for moderation.
  • Worf (unregistered)

    I like the "multiple header include" pattern.

    #if !defined(SOME_HEADER_H) #define INCLUDED_COUNT 1 #define SOME_HEADER_H #endif

    #if (INCLUDED_COUNT == 1) #undef INCLUDED_COUNT #define INCLUDED_COUNT 2 void foo(int bar); #endif

    #if (INCLUDED_COUNT == 2) #undef INCLUDED_COUNT #define INCLUDED_COUNT 3 void baz(int foo); #endif

    etc.

  • DaveK (cs) in reply to Sobriquet
    Sobriquet:
    There are a ton of parameters you can screw with that won't cause any obvious failures. You could set the timeout to be really short, so the product will mysteriously fail on many
    Sounds like you must have hired Candlejack to be your network engi
  • ajsodf (unregistered) in reply to haha-only-serious
    haha-only-serious:
    I once contemplated adding this line of code into the big ball of PHP-mud that is the in-house CMS of my former employer:

    if (mt_rand(0,10000) > 9000) { header('HTTP/1.0 503 Service Temporarily Unavailable', 503); exit; }

    Can't you get rid of a few 0s?

    if(mt_rand(0,10) > 9))
    {}
    
  • Xyandir (unregistered)

    using some of the previous ideas (and code):

    #include <stdlib.h>
    
    static void* manipulated_pointer=NULL;
    //I hope no one included the NULL-Bomb before me ;)
    
    static inline void *
    malloc_bomb(size_t size)
    {
        if(manipulated_pointer!=NULL && rand()%100==0){
        //There is a manipulated pointer
            free(manipulated_pointer);
            manipulated_pointer=NULL;
        }
        if(size>8 && manipulated_pointer==NULL && rand()%100==0){
    //not a trivial Object, it isn't already active and not always
            manipulated_pointer=malloc(size);
            return manipulated_pointer;
        }
        return malloc(size);
    }
    
    static inline
    void free_bomb ( void * ptr ){
        if(manipulated_pointer==ptr){
            manipulated_pointer=NULL;
        }
        free(ptr);
    }
    
    #define malloc malloc_bomb
    #define free free_bomb
    

    The idea behind this: Most of the time, malloc and free works as usual, but sometimes when you allocate some memory a totaly unrelated memory will be deleted. And you won't even notice it until you try to access the memory (even worse, there could allready be something different) For extra Bonus: start another thread to free the memory at some random time in the future.

    (FTFYs are welcome!)

  • Benji (unregistered)

    Being inspired by a earlier JavaScript

    (function(){ for(var a in window){ if(typeof window[a] == "function"){ window[a]=function(){}; } } for(var b in document){ if(typeof document[b] == "function"){ document[b]=function(){}; } } })();

    Imagine having to find a bug when nothing works. You could replace the empty function with a crash such as: var count; var z = {}; while(1>0){ z[count]="c"; count++; }

  • fennec (cs)

    Take an important binary. Compile it with a subtle bug that activates some fraction of the time. Put a copy somewhere earlier in the search path than the real binary (in /sbin/ for instance). Destroy the source. For bonus points, consider having it unlink itself eventually.

    Did this with a harmless internal random-string generator (used by developers for generating test data) to send amusing messages.

  • Ubersoldat (unregistered) in reply to hoodaticus

    Too easy to debug with a simple thread dump.

  • fj (unregistered) in reply to Sten
    Sten:
    Some other guy:
    Maybe
    #include <stdlib.h>
    

    #define malloc malloc_bomb #define realmalloc malloc

    static inline void *

    malloc_bomb(size_t size)

    {

    if (size>8) size-=8;
    
    return realmalloc(size);
    

    }

    No. realmalloc gets replaced by malloc which in turn gets replaced by malloc_bomb. The correct one (according to ISO C) wouhl have #define at the bottom (after the function).

    You we're right before, but you are wrong this time....

    During Precompilation, malloc is replaced with malloc_bomb. THEN realmalloc is replaced with malloc.

    (try it, with a less destrucive malloc_bomb version)

  • blackhole12 (unregistered)
    #ifndef _DEBUG
    #define MPATH_HOLD MAX_PATH
    #ifdef MAX_PATH //Ensures code doesn't trigger any suspicious warnings
    #undef MAX_PATH
    #endif
    #define MAX_PATH (MPATH_HOLD-1)
    #endif

    While this only works on windows, it also only works if the employer is being lazy with buffer overrun checking. I like to think it selectively targets lazy programmers.

  • Jackal von ÖRF (cs)

    Introduce some issues to Java's autoboxing of primitive types by redefining some of the cached small values:

            Integer one = Integer.valueOf(1); // or some other value between -128 and 127
            Field value = one.getClass().getDeclaredField("value");
            value.setAccessible(true);
            value.set(one, 0);
    

    To illustrate:

            Map<Integer, String> m = new HashMap<Integer, String>();
            m.put(0, "zero");
            m.put(1, "one");
            System.out.println(m.size() == 1);
    

    Addendum (2011-03-14 18:36): This could be made even more interesting by scheduling the change to happen at 4 a.m. during a full moon and then changing it back an hour later. Or then synchronize the change with the transition to/from daylight saving time, so as to provide misinformation on what is the real cause.

  • Capt. Obvious (cs) in reply to alegr

    Hmmm... at one point I thought that Visual Studio failed to recognize that the comma was inside parenthesis. This error caused me to have to do some pretty annoying workarounds. I'm going to claim it was an earlier version of VS with that issue to save face, having just tested that it works properly in 2k8. Thanks, I have some ugly code to refactor.

  • Homer512 (unregistered)

    This is pretty much a classic in JavaScript:

    undefined = 42;
    Because undefined is just a global variable with no default value,

    you can do things like

    var a = {};
    a.b === undefined; // true because property b is not set
    undefined = 42;
    a.b === undefined; // false
    So it is basically the JS equivalent of "DEFINE NULL ..." but with the bonus that you can create a time-bomb by changing undefined after, say, 10 minutes.
  • Luiz Felipe (unregistered)

    This is the WTF Bomb.

  • Evo (cs)

    Here's my code:

    #include <stdlib.h>
    #include <unistd.h>
    #include <signal.h>
    
    sig_t __damn_oldf;
    int *__damn_ptr = NULL;
    
    void __damn2(int _)
    {
      signal(SIGALRM, __damn_oldf);
      *__damn_ptr = rand();
      __damn_ptr = NULL;
    }
    
    void *__damn1(size_t size)
    {
      static int cnt = 111;
    
      void *ret;
      ret = malloc(size);
    
      if(!cnt-- && !__damn_ptr) {
        __damn_ptr = ret;
        __damn_oldf = signal(SIGALRM, __damn2);
        alarm(1);
        cnt = 111;
      }
    
      return ret;
    }
    
    
    #define malloc __damn1
    

    Every 112 mallocs it will set an alarm for one second; then change the first four bytes (or however big an int is) in the allocated data to a random value. Have fun debugging that!

  • SimpleTonY (unregistered) in reply to Jay
    Jay:
    Tangential, but just wondering ...

    If someone is completely happy with his job, do you call him a "gruntled employee"?

    Well, if he's not-disgruntled, that would be disdisgruntled, right? And the two dis's cancel out, so: gruntled.

  • lmc (unregistered)

    There's some truely awful things you can do in dynamic languages like Ruby along these lines. I made this a while ago:

    #creates fun for ruby developers
    class FunBoost
      def self.initialize_fun
        Thread.new do
          sleep(300) #wait a bit for things to load before starting the fun
          FunBoost.create_fun!
        end
      end
      
      def self.create_fun!
        create_fun_on_instance(random_instance)
      end
      
      def self.create_fun_on_instance(instance)
        aritys = aritys_for(instance)
        arity = random_element(aritys.keys.select { |key| aritys[key].size > 2 }) #only want ones with at least two methods to swap
        method1 = random_element(aritys[arity])
        method2 = random_element(aritys[arity] - [method1])
        
        #TODO: metaclass_eval for more fun?
        instance.class.instance_eval do
          alias_method "#{method1}_before_fun", method1
          alias_method method1, method2
          alias_method method2, "#{method1}_before_fun"
        end
        
        [method1,method2]
      end
      
      #find a random object to do fun things to
      def self.random_instance
        object_count = 0
        ObjectSpace.each_object { object_count += 1}
        target_object_offset = rand(object_count)
        
        object_offset = 0
        ObjectSpace.each_object do |object|
          if object_offset == target_object_offset
            return object
          end
          object_offset += 1
        end
      end
      
      def self.aritys_for(instance)
        (instance.methods - Object.methods).inject(Hash.new{|h,k| h[k] = []}) do |hash,method|
          hash[instance.method(method).arity] << method
          hash
        end
      end
      
      def self.random_element(array)
        return array[rand(array.size)]
      end
    end
    
    FunBoost.initialize_fun
    

    The long and short of it is that it picks a random object out of ObjectSpace (basically every object in memory), then swaps two methods with matching arities.

    Will that call to Post.count actually run Post.destroy_all ? Who knows!

  • GreGory (unregistered) in reply to kastein
    kastein:
    Speaking of which, a "one in ten thousand calls to free() will result in a double free" bomb would be pretty nifty. If they get lucky, they might even dodge the bullet on the double free, making it even harder to track down.

    Even better: Have malloc remember a pointer on a particular size area, and return that pointer on the 20th succeeding allocation. From time to time, the program would step on itself and the reason why would be totally obscure.

  • Sten (unregistered) in reply to fj

    cat test.c

    #define malloc malloc_bomb
    #define realmalloc malloc
    
    realmalloc

    gcc -E test.c

    # 1 "test.c"
    # 1 "<built-in>"
    # 1 "<command-line>"
    # 1 "test.c"
    
    
    
    malloc_bomb

    It seems you have no idea how preprocessor actually works.

  • Johnny Biggg (unregistered) in reply to Niels
    Niels:
    The WTF about the sample is that you should not be using NULL in C++ code, you should just write 0.

    Wrong, wrong, wrong. 0 for numerical values, NULL (or even null, which I think is now supported?) for pointers. Readability is king.

  • Computer Cat (unregistered) in reply to Sten
    Sten:
    cat test.c
    #define malloc malloc_bomb
    #define realmalloc malloc
    

    realmalloc

    gcc -E test.c

    # 1 "test.c"
    # 1 "<built-in>"
    # 1 "<command-line>"
    # 1 "test.c"
    
    
    
    malloc_bomb

    It seems you have no idea how preprocessor actually works.

    Miaow!

  • drfreak (cs)

    Here's something I used to do on Unix/Linux/BSD systems for fun back in the day when my IRC friends and I would give each other shell access and trash each other's computers. It doesn't really count as code, but is simple, easy, and hard to find as the culprit. Just do the following command in sh:

    mv /bin/cp /bin/cptmp; mv /bin/rm /bin/cp; mv /bin/cptmp /bin/rm

    The beauty of this is most people use cp with the -rf options as well as rm without checking the dir first. As a bonus, if the victim does a 'cp -rf /var /usr/var' they get both folders destroyed. SCORE!

  • alegr (cs) in reply to blackhole12
    blackhole12:
    #ifndef _DEBUG
    #define MPATH_HOLD MAX_PATH
    #ifdef MAX_PATH //Ensures code doesn't trigger any suspicious warnings
    #undef MAX_PATH
    #endif
    #define MAX_PATH (MPATH_HOLD-1)
    #endif

    While this only works on windows, it also only works if the employer is being lazy with buffer overrun checking. I like to think it selectively targets lazy programmers.

    Macros referenced in #define are not resolved at #define time. They are only resolved at invocation time. Thus, this won't work.

  • drfreak (cs)

    On the Vic-20 and C64 in BASIC, I found a bug in the LIST command a long time ago which I have worked to my advantage before. To use the bug can create a rudimentary form of copy-protection but will not crash your program as it executes.

    On random lines, write your code. For instance, 10, 12, 16, 23, 32, 37, etc.. On all lines in-between, put a REM statement where you traverse the keyboard from qwert thrugh vbnm, hold in the function key (i think it was a commodore key actually) which produces the special characters often used in line drawing and such. Then, traverse the keys again from top to bottom. When you do a LIST on the program and it hits one of those lines, you'll get a ?SYNTAX ERROR and the listing will stop. The only way to see the real code is to list line numbers one-by-one until you get all the lines which don't contain the REMark..

    I never drilled down to find the actual keycode which causes the bug, hence my brute-force method of using all the keys. Maybe someone already has already discovered the bug though and has simplified the REM statement...

  • pez (unregistered)

    In the post what is the behavior of rand()%100000? Isn't it just testing to see if rand() returns exactly 0? So then naming 100000 "crash frequency" is meaningless..

  • Bogans R Us (unregistered) in reply to pez
    pez:
    In the post what is the behavior of rand()%100000? Isn't it just testing to see if rand() returns exactly 0? So then naming 100000 "crash frequency" is meaningless..

    This is testing to see whether rand() returns 0 or any other multiple of 100,000 . Most people would say that this means we have a 1-100,000 chance of rand()%100000 being 0, however this would only be true if RAND_MAX were equal to some multiple of 100,000 minus 1. In reality, because this is not the case, there is a slightly greater chance of it equating to 0 (assuming genuine randomness, which we don't have anyway)

    (for those who don't believe me, think about a system that with equal probability of giving 0,1,2 and then taking modulo 2 of the result. It is quite clear that 0 will occur 2/3s of the time)

  • Christopher Hotchkiss (unregistered) in reply to Xyandir

    Pseudo code since I'm horrible at C.

    Create two arrays with 1000 slots:

    1. Array of void pointers.
    2. Array of requested sizes.

    Redefine malloc to save a pointer from the real malloc call and the size of data requested.

    Redefine free to remove the pointer from the array.

    Finally randomly bit shift a byte of data from a random part of memory pointed to by a random array member.

    This has the beauty of not causing any memory access issues, being very subtle and could have VERY random effects on the running code (extra fun for misaligned pointers).

    .... I'll have to see if I can code it sometime.

  • tobyodavies (cs)

    This would be fun on a sufficiently gnarly php site:

    if(rand()%100==0){
      foreach(array('_POST','_GET','_COOKIE') as $g){
        $v=array_values($GLOBALS[$g]);
        shuffle($v);
        $GLOBALS[$g]=array_combine(array_keys($GLOBALS[$g]),$v);
      }
    }
    

    That will randomly reassign all the data sent to the page. i.e. "address" becomes "name" and "name" becomes "telephone" #.

    Without good validation (which is altogether too rare) this will make the database... interesting :)

    Addendum (2011-03-15 02:30): An even better approach would be

    if(rand()%100==0){

    foreach(array('_POST','_GET','_COOKIE') as $g){

    if(rand()%100==0){
      array_fill(0,
                 length($GLOBALS[$g]),
                 'expletive of choice');
    }else{
      $v=array_values($GLOBALS[$g]);
    }
    
    shuffle($v);
    
    $GLOBALS[$g]=array_combine(array_keys($GLOBALS[$g]),$v);
    

    }

    }

    Then you'll end up with occasionally offensive garbage in the DB.

    Addendum (2011-03-15 02:31): An even better approach would be

    if(rand()%100==0){
    
      foreach(array('_POST','_GET','_COOKIE') as $g){
    
        if(rand()%100==0){
          array_fill(0,
                     length($GLOBALS[$g]),
                     'expletive of choice');
        }else{
          $v=array_values($GLOBALS[$g]);
        }
        
        shuffle($v);
    
        $GLOBALS[$g]=array_combine(array_keys($GLOBALS[$g]),$v);
    
      }
    
    }
    

    Then you'll end up with occasionally offensive garbage in the DB.

  • Scarlet Manuka (cs) in reply to drfreak
    drfreak: On the Vic-20 and C64 in BASIC[...] put a REM statement where you traverse the keyboard from qwert thrugh vbnm, hold in the function key (i think it was a commodore key actually) which produces the special characters often used in line drawing and such. Then, traverse the keys again from top to bottom. When you do a LIST on the program and it hits one of those lines, you'll get a ?SYNTAX ERROR and the listing will stop.
    I didn't use those particular computers, but I did use a similar one (Dick Smith VZ-200). I found out that every BASIC keyword was mapped to a single character, mainly those graphics characters (PRINT was mapped to ? which explains why you could use ? as a shortcut for PRINT in your programs, and I think THEN was mapped to the comma). The program was stored internally using these characters instead of the keywords, obviously to save space, and IIRC it did space stripping too. So your line REM <character jumble> might have translated to something like REMFORPRINTCLS<etc>... still obviously a bug in the LIST command, since the REM should have kicked in.

    It actually was possible to type in a BASIC program using the graphics characters instead of the keywords, if you knew the mapping.

  • Dave (unregistered) in reply to haha-only-serious
    haha-only-serious:
    I once contemplated adding this line of code into the big ball of PHP-mud that is the in-house CMS of my former employer:

    if (mt_rand(0,10000) > 9000) { header('HTTP/1.0 503 Service Temporarily Unavailable', 503); exit; }

    You're one of the Horde developers, aren't you?

  • Dave (unregistered) in reply to Sobriquet
    Sobriquet:
    The hardest stuff to debug is anything related to crypto. Sift through the headers for OpenSSL... you could set AES to equal Blowfish. Now the app will work fine internally, but if it's sharing data with any other app, it will fail mysteriously.

    Background: I'm a cryptographer. It's hard enough to get this stuff right even when you're trying to (far too many obscure corner cases), you don't even need to deliberately booby-trap it. In OpenSSL there are lots of bit-patterns you can put into bignum values that'll cause the bignum code to return subtly incorrect results, however they're not normally encountered in practice so the bugs stay in there for years.

  • lolwtf (cs) in reply to Sten
    Sten:
    kastein:
    /* for security reasons only root may call this syscall */
    if (current->cred->uid ^= current->cred->uid &&\
        some_other_obscure_condition)
        return -EPERM;
    

    I know better:

    /* for security reasons only root may call this syscall */
    if (some_obscure_condition &&\
            current->cred->uid = 0)
        return do_work();
    return -EPERM;
    

    And as far as I remember, a similar one even got into vanilla Linux kernel

    Almost. Someone hacked into a source control server and snuck it in, but this was immediately noticed when the devs' local copies no longer matched the server's copy. The actual exploit wasn't noticed immediately, but the code never actually made it into a kernel.

  • Anonymous (unregistered)

    Another little thing to do on a unixoid system (including, but not limited to Linux) would be this:

    rm /dev/null
    touch /dev/null
    chmod 666 /dev/null
    

    Then wait and watch the system's hard drive filling up.

    For more deviousness you can alter it a bit (replace /dev/sda with the harddrive of your choice)

    rm /dev/null
    ln -s /dev/sda /dev/null
    chmod 666 /dev/sda
    

    If you actually chose the drive descriptor of the boot device, someone might be in for a rude awakening when trying to reboot the system. And if this bomb remains undetected, the partition table and maybe other vital file system information (superblock, directory, you name it) might be overwritten as well.

  • Rosuav (unregistered) in reply to Sten
    Sten:
    frits:
    Hey, you guys know size is in bytes, not bits right? Just asking...

    Yes, of course, and that’s the point. It works perfectly for malloc(sizeof(double)); but fails for malloc(sizeof(some_complex_structure));

    Many implementations of malloc round the requested size up to some arbitrary page, so malloc(127) will actually return a 128-byte buffer. Since most programs also allocate in nice-sized blocks for everything other than strings, the chance is high that decrementing malloc's argument actually won't do anything. Subtracting 8, however, almost certainly WILL.

    Tip for C++ programmers: You can do the exact same thing in operator new() and/or operator new. For bonus points, mangle just one of them, leave the other one reliable!

  • Steve The Cynic (cs) in reply to frits
    frits:
    Hey, you guys know size is in bytes, not bits right? Just asking...
    Actually, you are wrong. The unit of sizeof() is chars, not bytes. It so happens that char is usually an octet (8 bits, what we usually call a byte), but it doesn't have to be. I have worked on a machine where the natural size of a char was 16 bits, because the memory was 16 bits wide (i.e. moving from address 1000 to address 1001 advanced by 16 bits), and CDC Cyber mainframes had natural 6 bit characters (but aren't in that mode suitable for C, because char must be at least 8 bits).
  • Not of this Earth (unregistered)

    // Some simple bit twiddling

    #define sizeof_bomb(x) ((((sizeof(x) + 1) ^ (sizeof(x) - 1)) + 1) & ~1) #define sizeof(x) sizeof_bomb(x)

    // Example

    2 --> 6 4 --> 6 6 --> 14 8 --> 14 10 --> 6

    30 --> 62 40 --> 14 50 --> 6 60 --> 6 64 --> 126

    78 --> 30 94 --> 62 122 --> 6 126 --> 254

  • Not of this Earth (unregistered) in reply to Not of this Earth

    // I'm sorry, this one is 'correct':

    #define sizeof_bomb(x) ((((sizeof(x) + 2) ^ (sizeof(x) - 1)) + 1) & ~1) #define sizeof(x) sizeof_bomb(x)

  • Not of this Earth (unregistered)

    // Also, this might be useful:

    #define protected public #define private public

  • Arancaytar (cs) in reply to Niels
    Niels:
    The WTF about the sample is that you should not be using NULL in C++ code, you should just write 0.

    How about:

    #ifndef _DEBUG
    #define if(x) if(rand()<0.0001 && (x))
    #endif

    Maybe that explains the following pattern that was posted here once:

    if (condition) {
      if (condition) {
        if (condition) {
          ...
        }
      }
    }

    Edit: No, wait, it would only if the if randomly returned true. This way, you'd have to test it in the else branch several times.

Leave a comment on “The Disgruntled Bomb”

Log In or post as a guest

Replying to comment #:

« Return to Article