Yeah, the sysadmin's a jerk...



  • Spending three afternoons interviewing a pretty bad batch of candidates (see Where do they FIND these people?) meant I had to spend a bit of time thinking back on the work I did for that company years ago. While I was chatting about it with a friend earlier tonight, he reminded me of the biggest laugh I ever got while looking over code there.

    Since the majority of people will completely miss the actual WTF, or think I'm missing one: Basically all computers of today use Two's Complement math. I.e., a signed byte ranges from -128 to +127. But on a One's Complement machine, a byte would range from -127 to +127: there are two zero values, +0 and -0. You could get -0 as easily as +0 on most systems just by adding and subtracting integers, but... The CPU instruction to test for zero/nonzero would generally only accept +0 as zero... negative zero would give the opposite result. And so on many machines, especially in assembler, you would see zero added to a value right before it was to be tested. On a modern CPU that's a laughable no-op, but on something old enough, leaving it off is a maddening to find bug.

    In C, since that's more readable:

    ix += 0;  /* The system admininstrator says this machine isn't 1's complement but I don't believe him */


  • But it's more portable, isn't it? I mean, you never know if one's complement comes back into fashion.
    And heck, what does a sysadmin know about the machines (s)he administrates anyway?



  • @Ilya Ehrenburg said:

    But it's more portable, isn't it? I mean, you never know if one's complement comes back into fashion.
    And heck, what does a sysadmin know about the machines (s)he administrates anyway?

    When their duties include repairing the system, using a logic probe to find the defective chip and a soldering iron to replace it? Quite a lot!

    And portability is a non-issue when the original code was assembler. I only put it in C for readability, remember... (My bad for not pointing that out, I guess.)



  • I thought the implicit <sar      /> tags were obvious, sorry.



  • @Ilya Ehrenburg said:

    I thought the implicit <sar      /> tags were obvious, sorry.

    In all fairness, they probably would have been if I hadn't pulled an all-nighter. :)



  • So the guy is a smart ass who knows about one's complement but is too stupid to actually check if his machine uses it or not.

     

    I assume the original code was not in C but out of curiosity:

    Wouldn't the C compiler insert the necessary instructions to assure -0 compares equal to 0 when compiling for a one's complement machine?

    And if you code in assembly the instructions set is probably different between one's and two's complement CPUs.



  • @topspin said:

    So the guy is a smart ass who knows about one's complement but is too stupid to actually check if his machine uses it or not.

     

    I assume the original code was not in C but out of curiosity:

    Wouldn't the C compiler insert the necessary instructions to assure -0 compares equal to 0 when compiling for a one's complement machine?

    And if you code in assembly the instructions set is probably different between one's and two's complement CPUs.

    As far as I know, no C compiler exists for any one's complement machine. But if one did, I would have to assume that it would either handle -0 correctly for us, either by accommodating it at point of test, or, probably more likely, by just doing everything in 2's complement behind our backs, so that data is more interchangeable in binary form.

    Every 1's complement machine I have ever personally seen, however, had a word length that wasn't a multiple of 8. 18 bit and 36 bit were common, and I've heard of a couple of 24 bit systems as well. A lot of these boxes use 6-bit characters, and many predate ASCII and use something entirely different. So I don't predict any of them running Linux soon. (I'm actually still astounded that someone's actually targeting the PDP-10 with GCC. It's a 36-bit machine that went out of production in 1984... but at least it tended to use ASCII and not something insane like Baudot code.)

    And the programmer responsible for that comment was responsible for many other code fragments that gave me a hell of a laugh. Usually more because of the comments because of the code itself. The guy was arrogant, only mildly, mildly clued in to reality, and he seemed to (I only know him by his code, I never met the guy) have some sort of paranoia complex, judging from: "Compiler authors added bugs just to get back at me for bug reports, uncomment next block when they fix it" appearing in the comment block above one function...



  • I don't often laugh out loud at these WTFs, but that comment did it for me. I guess machine architecture is much more subjective than I've been led to believe. "Does 0xFFFF represent -1 on this processor? Well, that's a matter of opinion, isn't it?"

     



  • @Wolftaur said:

    As far as I know, no C compiler exists for any one's complement machine.

    IIRC, ANSI C standard requires two's complement machine.



  • @alegr said:

    @Wolftaur said:

    As far as I know, no C compiler exists for any one's complement machine.

    IIRC, ANSI C standard requires two's complement machine.

    It might require two's complement behaviour, but it technically couldn't really require a two's complement machine. A one's complement machine can get two's complement behavior with a little extra work, and vice versa. Case in point: The IP header checksum is calculated with one's complement, not two's complement.

    Were one to compile C that implements this algorithm on a one's complement machine, it would break horribly, unless the compiler made sure that C math operations worked as if they were two's complement. This, however, would rapidly get annoying and inefficient: The magnitude difference. A byte in 1's complement is -127 to +127, a byte in 2's complement is -128 to +127. So you get to promote the type a lot while adding so you can catch that possibility...



  • @alegr said:

    @Wolftaur said:

    As far as I know, no C compiler exists for any one's complement machine.

    IIRC, ANSI C standard requires two's complement machine.

    Specification Lad to the rescue!

    @C99, 6.2.6.2(2) said:


    For signed integer types, the bits of the object representation shall be divided into three
    groups: value bits, padding bits, and the sign bit. There need not be any padding bits;
    there shall be exactly one sign bit. Each bit that is a value bit shall have the same value as
    the same bit in the object representation of the corresponding unsigned type (if there are
    [i]M[/i] value bits in the signed type and [i]N[/i] in the unsigned type, then [i]M[/i] ≤ [i]N[/i]). If the sign bit
    is zero, it shall not affect the resulting value. If the sign bit is one, the value shall be
    modified in one of the following ways:

    • the corresponding value with sign bit 0 is negated ([i]sign and magnitude[/i]);
    • the sign bit has the value -(2^N) ([i]two’s complement[/i]);
    • the sign bit has the value -(2^N - 1) ([i]one’s complement[/i]).

    Which of these applies is implementation-defined, as is whether the value with sign bit 1 and all value bits zero (for the first two), or with sign bit and all value bits 1 (for one’s complement), is a trap representation or a normal value. In the case of sign and magnitude and one’s complement, if this representation is a normal value it is called a [i]negative zero[/i].



  • @Ilya Ehrenburg said:

    I thought the implicit <sar      /> tags were obvious, sorry.
     

    Gets them every time...



  • @topspin said:

    So the guy is a smart ass who knows about one's complement but is too stupid to actually check if his machine uses it or not.

    The machine where you develop and the machine where your code runs are two different things. Sometimes you deliver code to a client, and the client compiles it on a new machine which doesn't match your development specs.

    ANSI C on a one's complement machine would be a compiler bug, but compiler bugs do exist, you know... and when we find them, we get to work around them, rather than demanding an upgrade.



  • @CDarklock said:

    @topspin said:

    So the guy is a smart ass who knows about one's complement but is too stupid to actually check if his machine uses it or not.

    The machine where you develop and the machine where your code runs are two different things. Sometimes you deliver code to a client, and the client compiles it on a new machine which doesn't match your development specs.

    ANSI C on a one's complement machine would be a compiler bug, but compiler bugs do exist, you know... and when we find them, we get to work around them, rather than demanding an upgrade.

    Scroll up to where I pointed out that while I posted the line as C for readability ... It was written in assembler. So the complement type of the machine isn't subject to change between different hardware configurations that are actually capable of running the code at all. :)



  • @Wolftaur said:

    Every 1's complement machine I have ever personally seen, however, had a word length that wasn't a multiple of 8. 18 bit and 36 bit were common, and I've heard of a couple of 24 bit systems as well. A lot of these boxes use 6-bit characters, and many predate ASCII and use something entirely different. So I don't predict any of them running Linux soon. (I'm actually still astounded that someone's actually targeting the PDP-10 with GCC. It's a 36-bit machine that went out of production in 1984... but at least it tended to use ASCII and not something insane like Baudot code.)

     

    ANSI C defines the constant CHAR_BIT in <limits.h> which is equal to the number of bits in a char variable. It also defines that all other variable types are even multiples of chars. int is at least 4 times the size of a char, but possibly larger. And there were some other constraints that I can't remember.

    All madness, since pretty much all modern machines use 8-bit chars. But some machines use differently sized ints.



  • @Spectre said:

    Specification Lad to the rescue!

    Specification Lad is my favorite member of the Legion of Writs! 



  • @morbiuswilters said:

    @Spectre said:

    Specification Lad to the rescue!

    Specification Lad is my favorite member of the Legion of Writs! 

    The guys who spout company policy are so much easier to laugh at though. And they make me ruin more keyboards with sudden coffee spewing. :)



  • "Compiler authors added bugs just to get back at me for bug reports, uncomment next block when they fix it"

    This part seems tongue in cheek to me.



  • @BentFranklin said:

    "Compiler authors added bugs just to get back at me for bug reports, uncomment next block when they fix it"

    This part seems tongue in cheek to me.

    I never personally met the guy, but a few others who dated back to when he was there said this sort of apparent paranoia from him was common, including spying on management, and other strange behavior. Maybe it was tongue in cheek, maybe he was just a bit nuts. The commentary was usually still funny. :)


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.