I wonder how many people back when this was widespread (don't tell me it still is?) actually set their computer clock to 2038 and see how a black hole is formed? I was pretty disappointed myself as nothing terrible happened, computer didn't even freeze.

And by the way, in Linux, everything is a FILE. Not necessarily a physical file or hard disks. You still don't get it. That includes your datagram, packets and streams. Would you accept a packet with date 00/00/00 at its header?

...yeah? Did you set your clock to 1 January 1970 or 1901 to find out (depends on signed/unsigned app usage)? My system still works perfectly fine after being set to that date (which is the exact same as overflow). How about try it for yourself and see how much of a "disaster" it really is? Grab an old Linux build/distro (without your so-called "patches") and place it in a VM and set it to 2038 or 1 Jan 1970/1901 and see how much of a catastrophe happens (it won't).

There's no patches needed. Not sure why you're blowing this out of proportions, in fact, since you said this is a nasty problem for Fasm, and I see it as totally minor (wrong dates, in an assembler?).

That's why I likened it to the Y2K "doomsday" ridiculous crap by the media, "all computers will shut down and we'll enter dark ages" and other nonsense even if unpatched. No, what happens is just that the date is wrong. And that's a totally minor issue, a slight inconvenience, not nasty.

BTW you don't need a patch to subtract one number from another. sub always works the same way. It handles overflow perfectly fine by design.    

Here we are talking about kernel code / C library in C. time_t is a C material, not ASM.

time_t has a TYPE. It's that type that is the main concern here. You can't simply modify x86 SUB instruction AND solve that TYPE problem because Linux kernel may exist on other architecture / CPUs, such as ATM/Banking machines, SPARC servers, IBM, GPS devices etc that may treat overflow very differently.

See, you fail to see the real problem here but you insist on telling people that you are a smart person.

So let me ask you one thing: If overflow is such an issue why don't you set the clock back by 10 years? The date will be wrong indeed, but is that a nasty problem for you? So stupid.

Besides, you're not doing anything importance to others using your PC. So you can break your own date software and of course nobody is affected. Why should I bother about you breaking your own PC? Are you writing time-critical server apps? banking apps that would really affect others? Nope. Your imaginary library is for high-end AVX-only PCs, remember? LOL.

So tell me, what the heck is "C material"? No seriously, give me a concrete definition.

Show me an architecture that doesn't use 2's complement.

Mind you, I specifically said that 2's complement has the magic of overflow handling builtin -- so clearly I already said architectures not using it are out of the question. blah blah blah

So what's this have to do with you setting backdate of your own PC again? Nothing.

We're talking about TYPE you idiot. Signed int is a signed int. It is part of the definition of a time data structure as defined by some C standard. What you're suggesting is done at the application layers, not from the kernel point of understanding or kernel development types of patches. Learn the differences between the two and you can save yourself the embarrasements.

Dude, there is no such thing as a "signed type mode" in a machine with 2s complement. So they compile to literally the exact same code. There's nothing to patch because it is THE SAME CODE.

/* gcc -m32 bug.c -s -o bug.exe */

#include <stdio.h>
#include <time.h>

int main(void)
{
    ;time_t     now;
    struct tm  ts;
    char       buf[100];

    //fast forward constants
    //time(&now);
    //now = 0;           //epoch
    now = 2147483647;  //max signed int
    //now = -2147483648; //signed overflow
    //now = 2147483648;   //attempt as unsigned

    ts = *localtime(&now);
    strftime(buf,sizeof(buf),"%a %Y-%m-%d ",&ts);
    printf("%s\n",buf);
    return 0;
}    

You're wrong. 2147483647 + 1 = 2147483648 in both asm and C, depending how you look at the value. Signedness is not in the value itself, it's in the instructions you use to operate on it.

In your case, you're talking about printing its value, which has nothing to do with asm nor C, but with the function you're using. (in this case printf). In your case, it's because that's what printf was designed to use for time.

Sign-ness is important in C's time function because ALL time-related C functions take only positive integers. The last two "now"s in the above code won't work. The system hangs on you for the obvious reasons.

NO. Not interested in the output. It's just a tool of proof. It's the "localtime()" function that is the concern here because the last two "now"s are negative integers. Not strftime and nor printf. You can disable both and still your code freezes for the last two "now"s due to inappropriate argument (negative integers) fed to localtime().

sub eax, edx    

The signedness of the type doesn't matter one bit to the function you pass it

-2147483648 = 2147483648 in terms of 32-bit number representation. Its bit value is 0x80000000 -- literally nothing else (there's no "type" embedded in values).    

So no, that's precisely what the topic was, you drifted way off topic with C "stuff", not me.

And this tm / time_t data structure doesn't necessarily mean "database" as per your pathetic definitions. This faulty data structure exists on nuclear missiles controllers, bullet train controllers, aviation / navigation devices and controllers etc. They exist where C exists and / or Linux kernel exists.

The Y2038 bug has nothing to do with C

Just like an encrypted file has no meaning, only a collection of bits. What matters is the reader of those bits (the program, or "function" in this case). The reader is what gives a specific purpose to those bits and makes them "signed" or not (or decrypts them, whatever). By this, it is extremely obvious you have absolutely no idea about computer science and information theory in general. Stop parroting media bullshit you read without understanding it.

Prove that those systems will freeze when they have incorrect date.

Also, Windows? This is 1) Linux section 2) Unix time bug. Stop looking at half-assed implementations (and even in Windows it's highly doubtful it freezes, mine didn't freeze btw but I'm on Wine so... you're probably lying).

Keep parroting bullshit like how X and Y and other controllers depend on dates and not time deltas as I've said so many times before. (nuclear stuff even has passive safety, you just don't know anything)

Integer overflow can be a serious problem. But this isn't just integer overflow. This is integer overflow on dates, and dates are (mostly) minor stuff. Get over it.

Integer overflow also occurs in field of medicine, finance, rocket science.

I'm not here to educate you, go read a book or something and follow your own advice, it seems you can't even read a simple wiki page.

I don't need wiki.

Many transportation systems from flight to automobiles use embedded systems extensively. In automotive systems, this may include anti-lock braking system (ABS), electronic stability control (ESC/ESP), traction control (TCS) and automatic four-wheel drive; aircraft may use inertial guidance systems and GPS receivers. However this does not imply that all these systems will suffer from the bug. Many such systems will not require access to dates. For those that do, those systems which only track the difference between times/dates and not absolute times/dates will, by the nature of the calculation, not experience a problem. This is the case for automotive diagnostics based on legislative standards such as CARB (California Air Resources Board).