The Daily WTF: Curious Perversions in Information Technology

2013-03-05 Reply Admin

Damien:
B:
TRWTF is that 2^64 seconds is only 584,542,046,091 years. 35,096,545,043,317 AD is closer to 2^70 seconds away.
Actually, it's quite a few years more than that. You've used the approximation of 365.25 days per year, which ignores the century leap year rule...

If by "approximation" you mean "definition", then sure.

2013-03-05 Reply Admin

Looks more like an excrement function than an increment function.

2013-03-05 Reply Admin

if (_totalSeconds < ulong.MaxValue) { _totalSeconds += 1; } else { _totalSeconds = 0; _totalOverflows += 1; }

Fixed?

PiisAWheeL · 2013-03-05 Reply Admin

Russ:
Sometimes, you just get a little paranoid.

Winner! ^__i_^

chubertdev · 2013-03-05 Reply Admin

Is ParanoiaOverflow.com part of the StackExchange network?

Zylon · 2013-03-05 Reply Admin

We've got a kill screen coming up everyone! Kill screen everyone! Kill screen!

dkf · 2013-03-05 Reply Admin

snoofle:
Sherman:
Anon:
But what if we hit that ubiquitous rip in the space/time continuum and suddenly time ran backwards so that the ulong went negative? Ka-POOF!
Wait...what does the u in ulong stand for?
ubiquitous and/or continuum, or perhaps unusually long

It stands for unsigned. You know, without a digital signature attached.

2013-03-05 Reply Admin

Harrow:
If I saw this in a program
   _totalSeconds += 1;   // ulong
without the overflow check, the first thing I would do would be to use the debugger to set
   _totalSeconds
to 18,446,744,073,709,551,613 and let it run.

-Harrow.

Linux does this - I believe its jiffies counter is set to about 2 minutes before wrapping around (if there's not a setting to adjust how long you have until it wraps) for this very purpose (because the counter typically takes a long time to wrap, but not long enough that a stable system wouldn't encounter it).

2013-03-05 Reply Admin

The code is actually counting "seconds", i.e., second helpings passed out. The target audience being indvidual bacteria, it's quite possible for this to overflow.

2013-03-05 Reply Admin

Sherman:
Anon:
But what if we hit that ubiquitous rip in the space/time continuum and suddenly time ran backwards so that the ulong went negative? Ka-POOF!
Wait...what does the u in ulong stand for?

Exactly my point!

2013-03-05 Reply Admin

B:
Damien:
B:
TRWTF is that 2^64 seconds is only 584,542,046,091 years. 35,096,545,043,317 AD is closer to 2^70 seconds away.
Actually, it's quite a few years more than that. You've used the approximation of 365.25 days per year, which ignores the century leap year rule...
If by "approximation" you mean "definition", then sure.

Wikipedia:
Nevertheless, because an astronomical Julian year measures duration rather than designating a date, this Julian year does not correspond to years in the Julian calendar or any other calendar. Nor does it correspond to the many other ways of defining a year.

So, if you want to know the date, you have to include the leap year exceptions at every 100 years, along with the exception exceptions at every 400 years.

2013-03-05 Reply Admin

It's probably more like "u long, bro?" but without the coder getting a sexual harassment suit from his boss.

2013-03-05 Reply Admin

Thought the same thing :

ThaMe90:
I wouldn't be surprised _totalSeconds is of a different type than ulong.

Double WTF possible

2013-03-05 Reply Admin

I kid you not...

Inserting random bit errors in memory was part of the 'official' static discharge robustness testing procedure for embedded devices at one of the companies I used to work at.

2013-03-05 Reply Admin

snoofle:
Harrow:
Vanders:
Harrow:
the first thing I would do would be to use the debugger to set _totalSeconds to 18,446,744,073,709,551,613 and let it run.
Which would tell you what, exactly?
Three seconds later I would find out what happens to the program when _totalSeconds overflows.
-Harrow.

You would discover that somewhere in the code that wraps this function call is something like this:
  try {
      ...
      if (_totalSeconds < ulong.MaxValue) {  
         _totalSeconds += 1;
      } else {  
         _totalSeconds = 0;  
      }
      ...
  } catch (Exception e) {
    _totalSeconds = 0; // time-space continuum rift
  }

You should be catching the more specific SpaceTimeContimuumException rather than just Exception. That's best practice.

2013-03-05 Reply Admin

Terry:
if (_totalSeconds < ulong.MaxValue) { _totalSeconds += 1; } else { _totalSeconds = 0; _totalOverflows += 1; }
Fixed?

What happens when totalOverflows overflows?

2013-03-05 Reply Admin

Valued Service:
B:
Damien:
B:
TRWTF is that 2^64 seconds is only 584,542,046,091 years. 35,096,545,043,317 AD is closer to 2^70 seconds away.
Actually, it's quite a few years more than that. You've used the approximation of 365.25 days per year, which ignores the century leap year rule...
If by "approximation" you mean "definition", then sure.

Wikipedia:
Nevertheless, because an astronomical Julian year measures duration rather than designating a date, this Julian year does not correspond to years in the Julian calendar or any other calendar. Nor does it correspond to the many other ways of defining a year.

So, if you want to know the date, you have to include the leap year exceptions at every 100 years, along with the exception exceptions at every 400 years.

Yes, the approximation, 365.2425 days/year, will generally give you a better result. At least, anywhere using the Gregorian calendar.

2013-03-05 Reply Admin

B:
Damien:
B:
TRWTF is that 2^64 seconds is only 584,542,046,091 years. 35,096,545,043,317 AD is closer to 2^70 seconds away.
Actually, it's quite a few years more than that. You've used the approximation of 365.25 days per year, which ignores the century leap year rule...
If by "approximation" you mean "definition", then sure.

That's the wrong calendar. The world moved on to Gregorian, during Pope Gregory XIII's reign. That was nearly 500 years ago.

2013-03-05 Reply Admin

She said I was long enough, but we added seconds and I overflowed.

2013-03-06 Reply Admin

Vanders:
Harrow:
Three seconds later I would find out what happens to the program when _totalSeconds overflows.
Do you break out your debugger and start changing random bits in memory just to see what will happen, too?
We can read the code and see what will happen...

Are you sure you know what will happen? Can a Pentium even detect a 64b unsigned integer overflow? If so, does the compiled code ignore the condition? Or generate an exception? Is the code called from within in a try..except block? Where is the exception caught? In short, what is the gross behavior of the program?

You may look at

   _totalSeconds += 1;

and convince yourself that you know what will happen; I prefer to avoid potentially expensive surprises.

-Harrow.

Steve The Cynic · 2013-03-06 Reply Admin

Captain Oblivious:
That's the wrong calendar. The world moved on to Gregorian, during Pope Gregory XIII's reign. That was nearly 500 years ago.

Um, no. The Roman Catholic world (actually only four countries of it) moved in 1582[*], during Gregory XIII's reign. Great Britain moved in 1752, as did its various overseas doodads. The last secular authority in Europe to move was Greece, in 1923. The last government anywhere to adopt it was pre-revolutionary China, in 1929.

[*] That's 441 (not quite) years ago, far enough from 500 for "nearly 500 years ago" to be a questionable use of "nearly". Well, I'm questioning it, anyway. I would, however, accept "nearly 450".

Overall, then, you'd be better off saying that the world "began moving on to Gergorian during the reign of Pope Gregory XIII. That was nearly 450 years ago."

Addendum (2013-03-06 03:46): Oops, arithmetic failure. 431 years ago. Sorry.

Steve The Cynic · 2013-03-06 Reply Admin

Harrow:
Are you sure you know what will happen? Can a Pentium even detect a 64b unsigned integer overflow? If so, does the compiled code ignore the condition? Or generate an exception? Is the code called from within in a try..except block? Where is the exception caught? In short, what is the gross behavior of the program?

Yes, it can. Any arithmetic operation on x86/x64 that generates unsigned overflow will set the "carry out" flag in the CPU's status word. You can branch on that to do different things in the carry and no-carry cases.

Signed overflow is detected by a difference in the carry in and out of the highest bit of the operation, and sets the "overflow" flag in the CPU's status word. x86 (and presumably x64, not tried) has an instruction "INTO" that generates a specific software trap if the overflow flag is set.

MSDOS would, by default, catch this trap, print a message, and abort the program. I'd imagine that Windows will redirect it into a SEH exception, although possibly not one that the C/C++ runtime will convert into something useful, and (on VC6+) it will therefore be caught only by catch(...) blocks (so you can't tell what happened).

But most compilers won't insert code to fire this trap, so it isn't going to happen.

2013-03-06 Reply Admin

Roby McAndrew:
(Yes, I've worked on hardware where you can't trust the contents of RAM).

So did you develop any "design patterns" and "best practices" like this: const int a = 5; assert(a == 5); // computations assert(a == 5); // just to be certain

Also, if you can't trust RAM, why do you trust ALU? bool canTrustALU() { return ((5 * 3 == 5 + 5 + 5) && (18 / 3 == 2 * 3)); }

What I mean is that unless you program for a hardware that runs in harsh environment (e.g. in places with lots of radiation) memory corruptions should be fixed (as they are most likely caused by dangling pointers, etc.) rather than worked around.

2013-03-06 Reply Admin

My guess is that it was done this way because some linting tool issued a warning of possible overflow on the ++.

Linting tools are a very useful item, but blindly following everything they say isn't always the best option.

[captchas .... you know they're weak when the browser's autosuggest feature guesses the right word as soon as you start typing]

2013-03-06 Reply Admin

Seriously, your dealing with overflows? I told my manager I need a 1024-bit architecture and whenever something overflows I say: "Hey, I said so. This bug occurs because you did not buy the hardware I asked for!"

2013-03-06 Reply Admin

Perl's gmtime() will output nothing if the year is greater than 0x7fffffff.

2013-03-06 Reply Admin

Valued Service:
B:
Damien:
B:
TRWTF is that 2^64 seconds is only 584,542,046,091 years. 35,096,545,043,317 AD is closer to 2^70 seconds away.
Actually, it's quite a few years more than that. You've used the approximation of 365.25 days per year, which ignores the century leap year rule...
If by "approximation" you mean "definition", then sure.

Wikipedia:
Nevertheless, because an astronomical Julian year measures duration rather than designating a date, this Julian year does not correspond to years in the Julian calendar or any other calendar. Nor does it correspond to the many other ways of defining a year.

So, if you want to know the date, you have to include the leap year exceptions at every 100 years, along with the exception exceptions at every 400 years.

Which is precisely why I didn't specify a date. I specified a number of years, which is different. That's why I said "584,542,046,091 years" and not "584,542,048,104 AD". Dates beyond 5 - 6 billion years from now are entirely useless due to the red giant phase of the sun, so I did not use them. I used the standard astronomical year, which has nothing whatsoever to do with a calendar year.

As for the other calculation I used, 35,096,545,043,317 AD is still going to be closer to 2^70 seconds regardless of what arbitrary earth-centric calendar year you choose to use. Even if you choose to say that the year is 365.242 days long, or 365.242154861484384 days long, it does not matter because the value of the highest order of magnitude hasn't changed.

You could say that a year is 30,000,000 seconds and that the date is 30,000,000,000,000, or you could say that a year is 39,999,999 seconds and the date is 39,999,999,999,999 and you're still close to 2^70:

30,000,000 * 30,000,000,000,000 = 9 * 10^20 log(9 * 10^20)/log(2) ~= 69.61

39,999,999 * 39,999,999,999,999= 1.6 * 10^21 log(1.6 * 10^21)/log(2) ~= 70.42

So, yes, as long as a year is roughly 300-399 days, 35,096,545,043,317 AD is about 2^70 seconds away.

2013-03-06 Reply Admin

Captain Oblivious:
B:
Damien:
B:
TRWTF is that 2^64 seconds is only 584,542,046,091 years. 35,096,545,043,317 AD is closer to 2^70 seconds away.
Actually, it's quite a few years more than that. You've used the approximation of 365.25 days per year, which ignores the century leap year rule...
If by "approximation" you mean "definition", then sure.

That's the wrong calendar. The world moved on to Gregorian, during Pope Gregory XIII's reign. That was nearly 500 years ago.

Yes, but I live in the former British North American colonies, and we didn't switch over until 1752. You can hardly expect us to have everything updated for such a recent change.

2013-03-06 Reply Admin

Captain Oblivious:
That's the wrong calendar. The world moved on to Gregorian, during Pope Gregory XIII's reign. That was nearly 500 years ago.

Now that I think about it, who says the Gregorian calendar is "right" and the Julian calendar is "wrong"? A Gregorian year more nearly approximates the amount of time it takes the Earth to go around the sun, but who says that that's the criteria? Arguably a simpler calendar is "better" even if it does not match an astronomical year as closely.

And isn't it rather culturally chauvinistic to use a European calendar? Why not the Islamic calendar? Millions of people in the world use that, and its months more nearly approximate an astronomical month than Gregorian or Julian months do.

To say that the Gregorian calendar is 500 years newer seems like a rather trivial number when we are talking of a time scale of billions or trillions of years.

2013-03-06 Reply Admin

Krzysiek:
Roby McAndrew:
(Yes, I've worked on hardware where you can't trust the contents of RAM).
So did you develop any "design patterns" and "best practices" like this: const int a = 5; assert(a == 5); // computations assert(a == 5); // just to be certain
Also, if you can't trust RAM, why do you trust ALU? bool canTrustALU() { return ((5 * 3 == 5 + 5 + 5) && (18 / 3 == 2 * 3)); }

What I mean is that unless you program for a hardware that runs in harsh environment (e.g. in places with lots of radiation) memory corruptions should be fixed (as they are most likely caused by dangling pointers, etc.) rather than worked around.

In modern times, programs like memtest86 are common because RAM failures are more common than ALU failures. Of course they're less common than software failures but they happen often enough that memtest86 is kind of an important program.

Some systems test if two (or five) CPUs agree on the result of a computation. When they don't all agree, they delay the space shuttle, or they repeat the computation or they try a fallback route. Sometimes it turns out that the space shuttle was delayed because of a software bug, but even so, the comparison tests serve their purpose.

Some of the giants of the industry figured out how to get reliable results on unreliable hardware in the 1940's. Too bad that technology has been lost.

2013-03-06 Reply Admin

jay:
Captain Oblivious:
That's the wrong calendar. The world moved on to Gregorian, during Pope Gregory XIII's reign. That was nearly 500 years ago.
Yes, but I live in the former British North American colonies, and we didn't switch over until 1752. You can hardly expect us to have everything updated for such a recent change.

Well some of the most important things were updated, such as George Washington's birthday. He shifted his birthdate in order to keep his age in days correct in the new calendar.

2013-03-07 Reply Admin

Norman Diamond:
Krzysiek:
(...)
What I mean is that unless you program for a hardware that runs in harsh environment (e.g. in places with lots of radiation) memory corruptions should be fixed (as they are most likely caused by dangling pointers, etc.) rather than worked around.

In modern times, programs like memtest86 are common because RAM failures are more common than ALU failures. Of course they're less common than software failures but they happen often enough that memtest86 is kind of an important program.
Some systems test if two (or five) CPUs agree on the result of a computation. When they don't all agree, they delay the space shuttle, or they repeat the computation or they try a fallback route. Sometimes it turns out that the space shuttle was delayed because of a software bug, but even so, the comparison tests serve their purpose.

Some of the giants of the industry figured out how to get reliable results on unreliable hardware in the 1940's. Too bad that technology has been lost.

Somehow I doubt that genuine RAM failures are common. I rather think that the tools like memtest86 are only used by overclockers who want to know how many more Hz they can squeeze of the hardware. Of course I did not do any Internet-wide survey to confirm this...

I agree that redundancy and robustness in mission-critical systems is, well, critical, and it is better to err on the safe side (e.g. delay the launch). This is also where all the hardware tools like watchdogs and brownout detectors come from and where special checks in software are needed. However, badly soldered HW is not a good reason to add paranoia to SW.

2013-03-07 Reply Admin

If it's a signed long, it will always be less than ulong.max_avlue.

2013-03-07 Reply Admin

Krzysiek:
Norman Diamond:
Krzysiek:
(...) What I mean is that unless you program for a hardware that runs in harsh environment (e.g. in places with lots of radiation) memory corruptions should be fixed (as they are most likely caused by dangling pointers, etc.) rather than worked around.
In modern times, programs like memtest86 are common because RAM failures are more common than ALU failures. Of course they're less common than software failures but they happen often enough that memtest86 is kind of an important program.
Some systems test if two (or five) CPUs agree on the result of a computation. When they don't all agree, they delay the space shuttle, or they repeat the computation or they try a fallback route. Sometimes it turns out that the space shuttle was delayed because of a software bug, but even so, the comparison tests serve their purpose.

Some of the giants of the industry figured out how to get reliable results on unreliable hardware in the 1940's. Too bad that technology has been lost.
Somehow I doubt that genuine RAM failures are common.

Doubt as much as you want, the fact is that they are common, not as much as software failures but a lot more than ALU's. Sometimes it's caused by an ungrounded user discharging static electricity into their PC when they power it up in the morning. Sometimes it's caused by hardware designers not paying enough attention to heat flow through a Dell laptop.

Krzysiek:
I rather think that the tools like memtest86 are only used by overclockers ...

If you change "only" to "more often" I might agree. The machines where I've needed it weren't overclocked.

Krzysiek:
However, badly soldered HW is not a good reason to add paranoia to SW.

Wrong. Parity checking used to be common on every kind of computer except PCs and Crays, and when they detected failures they didn't try to distinguish bad soldering from any other reason. When Cray finally figured out that parity checking might not be a bad idea, he was shocked to discover that parity checking was doing its job. The absence of parity checking in PCs is one of the biggest WTFs in current practice.

2013-03-08 Reply Admin

While the situation it is guarding against is unlikely, this code isn't really a WTF. I'd rather see an unnecessary guards due to a paranoid programmer than no guards at all.

2013-03-11 Reply Admin

I don't think this will work at all. When the value overflows it will become negative, and still be less than max long value.

2013-03-12 Reply Admin

Norman Diamond:
Krzysiek:
Somehow I doubt that genuine RAM failures are common.
Doubt as much as you want, the fact is that they are common, not as much as software failures but a lot more than ALU's. Sometimes it's caused by an ungrounded user discharging static electricity into their PC when they power it up in the morning. Sometimes it's caused by hardware designers not paying enough attention to heat flow through a Dell laptop.

OK, so how common is common? One RAM failure per machine per 5 years (per a year? two months?)? Are we talking about machines standing in offices or hardened microcontrollers installed in Chernobyl monitoring equipment?

Norman Diamond:
Krzysiek:
I rather think that the tools like memtest86 are only used by overclockers ...
If you change "only" to "more often" I might agree. The machines where I've needed it weren't overclocked.

How many machines was this? How many machines have you seen in total?

Norman Diamond:
Krzysiek:
However, badly soldered HW is not a good reason to add paranoia to SW.
Wrong. Parity checking used to be common on every kind of computer except PCs and Crays, and when they detected failures they didn't try to distinguish bad soldering from any other reason. When Cray finally figured out that parity checking might not be a bad idea, he was shocked to discover that parity checking was doing its job. The absence of parity checking in PCs is one of the biggest WTFs in current practice.

Lack of proper quality checks would be the TRWTF. Can you imagine a company doing business by selling poorly soldered HW on top of which there is SW desperately trying to recover from errors?

In my experience HW (solid state, I'm not talking about mechanical parts) is orders of magnitude more reliable than SW. What are the chances that a company doing sloppy job soldering HW can excell at SW?

2013-03-12 Reply Admin

Krzysiek:
Norman Diamond:
Krzysiek:
Somehow I doubt that genuine RAM failures are common.
Doubt as much as you want, the fact is that they are common, not as much as software failures but a lot more than ALU's. Sometimes it's caused by an ungrounded user discharging static electricity into their PC when they power it up in the morning. Sometimes it's caused by hardware designers not paying enough attention to heat flow through a Dell laptop.
OK, so how common is common? One RAM failure per machine per 5 years (per a year? two months?)? Are we talking about machines standing in offices or hardened microcontrollers installed in Chernobyl monitoring equipment?

I cringe when I see a particular manufacturer's name on medical equipment, but that's because of software or firmware rather than RAM (though they used to make RAM too). Chernobyl was destroyed by a WTF human operation and Fukushima was destroyed by a WTF physical layout (it was beyond the imagination of bureaucrats and pointy haired bosses that a tsunami could come as big as the ones that came in 1896 and 1933). But I do not get to work on those.

Some are office machines used by me or co-workers, some are owned by myself, some are owned by friends who know I have computer experience, etc.

Krzysiek:
Norman Diamond:
Krzysiek:
I rather think that the tools like memtest86 are only used by overclockers ...
If you change "only" to "more often" I might agree. The machines where I've needed it weren't overclocked.
How many machines was this? How many machines have you seen in total?

I suppose that out of 200 machines I've seen bad RAM on 10. I've seen bad CPUs on 0 (no estimation needed for this 0). I've seen bad hard drives on around 10 and bad graphics chips on around 3.

Krzysiek:
Lack of proper quality checks would be the TRWTF.

Yup. Along with firing anyone who dares to propose quality checks.

2013-03-13 Reply Admin

Freudian Trousers:
Someone set us up the Auditor!

Set up us! Set UP US!

If you're gonna do it, do it right.

2013-03-22 Reply Admin

TRWTF is that if _totalSeconds really was ulong.MaxValue, and it was incremented by 1, it would automatically be 0 because arithmetic is modulus. This entire if statement is redundant.

...

Although, in some interpreted languages, it would just stay at ulong.MaxValue.

And in some managed languages, it would throw an exception.

But in those cases, it's safe to say that those evil languages are TRWTF.

A Long Running Process

Leave a comment on “A Long Running Process”