flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Linux > 2038 problem (split-off thread)

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
system error



Joined: 01 Sep 2013
Posts: 522

Furs wrote:
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.



It's hard to explain these things to non-technical guy.

Linux systems are used in embedded components AND servers that keep on running until time_t runs out of bits. How do you fix your car's 32-bit GPS date anomaly? Burn it up? That includes LOTS of aviation components too!

You won't catch that bug on your PC right now if you changed the date because your kernel code / OS have probably already been updated / fixed / patched very quickly when the bug was first heard some years ago. But still there are many critical components out there implementing the old time data structure. One of such example is EXT3 filesystem which uses 32-bit signed timestamp. Last time I heard, there's no serious remedy for it even from the likes of UNIX.
Post 09 Jul 2017, 17:18
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 567
Except it's not a "problem". That's what I meant. At worst, it's an inconvenience if you rely on accurate absolute timestamps. Look, even systems that rely on gradual timestamps won't suffer from it. That is, if you need only relative time passed since last "run" for instance, then it's no problem at all. That's because of the beauty of 2's complement number representation (which is what x86 and probably every architecture out there is using).

Let's use a simple example with an 8-bit number. It overflows after the value 255. Now let's say we run it when it's the value 250. Next time we run it, it overflowed and is back to 10.

So we perform the relative time change, which is 10-250. Discard the upper bits above 8 (because example is 8-bit number), and the result is 16, which is correct as if it never overflowed at all. Magic.

Of course that's a problem if it overflows twice before it even has the chance to update itself, but that means like waiting 80 years or whatever between running it again. Anyway, most systems don't rely on absolute timestamps, they rely on time deltas which don't mind overflow at all.

EXT3 for example will simply give the wrong timestamp for files. Not a huge dealbreaker and if worst comes to worst it's easily transferred to another filesystem. If this is a huge problem like the media hypes it up, then I presume a dead hard drive is even worse since you can't even read files from it anymore!
Post 09 Jul 2017, 17:31
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 522
What you're suggesting is patches / fixes. I mentioned that in third paragraph. Everybody can provide a patch to such overflow problem. I am not talking about some patches or what you can do because that doesn't take away the facts that the component in question is STILL faulty. Patches and fixes are not cheap. It can translate to MASSIVE RECALLS.

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?
Post 09 Jul 2017, 18:31
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 567

system error wrote:
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 13 Dec 1901 to find out? My system still works perfectly fine after being set to that date (which is the exact same as overflow on "broken" systems). How about try it for yourself and see how much of a "disaster" it really is? Alternatively grab an old Linux build/distro (without your so-called "patches") and place it in a VM and set it to 2038 or 13 Dec 1901 and see how much of a catastrophe happens (it won't).

There's no patches needed unless the application's purpose itself is manipulating dates precisely. (a calendar for example) 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. They even compared it with Excel spreadsheets and other random stuff how all the YY representation will be broken. So what? Insignificance.

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. Only problem is if you read the date or compare it.


Hey, in the worst case just manually set your date back 10 years every 10 years, so your device is forever stuck in the 201x era, does it seem like such a big deal? Even for a calendar, it's a minor inconvenience since you'll have to manually adjust the date (i.e. you know you're in 204x, and your super old device shows 2017, so you know it's 2047, big deal?). Filesystem dates are totally irrelevant unless you use an app that uses them (a backup tool for example).

I don't know about you but I consider a device being literally broken with no ability to use it or restore it as "nasty" problem, not something like this. Wink
Post 10 Jul 2017, 13:33
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 522

Quote:
...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).



of course it wont because the kernel code / lib have already been fixed for you. I think I have already answered it twice, three times including this one. You still have big problem in reading comprehensions. You're a complete waste of time.

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.


Quote:
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?).



You clearly showing your big incompetency in understanding the overall picture. Here are two links of the patching work needed and it is still in progress. Where did you get the idea that this bug don't need patching? From your own imaginary libraries? Hahaha Very Happy

https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.7-More-Y2038-Work
https://www.neowin.net/news/torvalds-unhappy-with-sloppy-unix-millennium-bug-patches-for-linux-kernel

I didn't say it's nasty problem for FASM. It's from your own mouth. I did say "that nasty Y2038 problem". See, you're going emotional again


Quote:
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.



I never said anything about Y2k, black hole, dark ages and stuff. They are all coming from your own craps.


Code:
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. If I were your employer, I'd make sure you are unemployed because of your statement that all corporation servers running on 32-bit Linux don't need any Y2038 patches.
Post 10 Jul 2017, 14:49
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 567
Your links don't prove your point, in fact you don't even understand them. Not surprised since you probably don't even code and just read hyped articles. Of course the kernel needs patching for it. What's your point? Since, you know, the kernel needs to give out accurate timestamps for applications who need it. It's obviously a problem, it's just that it is minor and of no consequence. You might be surprised, but minor problems get patched too!

If the kernel doesn't report the date properly after 2038, then it needs patching so it does, but that doesn't mean it is a nasty problem, get over it. There's millions of minor patched problems. This one is only famous because it is impossible to fix without changing the interface, and the media loves clueless morons hyping up to doomsday dates.

So it's not that it is a nasty problem, it's just hard to fix for legacy applications that won't get recompiled. You can't change the API without recompiling all the applications that depend on it.

For FASM of course, you said (or assumed) it doesn't support 64-bit timespec, so again show me what tragedy that causes. If you cared (before asking) so much of such minor problem then call the syscall manually. It's not even difficult. Because it's not nasty, it's totally minor and overblown.

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.


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

I've no idea what this is supposed to mean. Clearly you think you're not talking to a person who sent many patches to GCC. So tell me, what the heck is "C material"? No seriously, give me a concrete definition.

Every type in GCC, when lowered, maps to a machine mode. This is regardless of the architecture it supports. Since your "C material" is compiled by a C++ compiler and GCC supports the most architectures out of any major compiler, then it must be doing it right.

Each machine mode (QI, HI, SI, DI) directly maps to accesses on x86 and other architectures -- QI = 1 byte, HI = 2 bytes, ... (for x86, there's even machines with differently-sized bytes, nothing changes, GCC compiles for them too)

This has to do with one and one thing only: whether the numbers are represented via 2s complement on the target machine or not. Nothing about your delusional "C material" thing. I specifically said about 2s complement though, so I'm not sure what your point even is? Telling me it won't work on the ultra-rate architecture without 2s complement is telling me something I've already stated.


system error wrote:
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.

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.

Not that I can find any relevant ones, though.


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

Ever thought you're the only one who brings and thinks such shit up?

Ever thought other people just argue with... arguments instead? Stop reflecting your coding insecurity on others!

Might want to re-read posts a bit and realize who's trying to prove himself.
Post 10 Jul 2017, 16:21
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 522

Quote:
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.



I think I already gave you the answer up there. But since you have problem with reading comprehensions, here's one, re-quoted (the second time):


Quote:
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.



Since you are not giving me any quality answer, then I took it that you're not writing any time and date critical apps. Just you and your imaginary library and your PC probably in your basement.

For financial, online transactions, and banking systems to calculate Net Present Value (NPV), ROI, Rate-of-Return, Payback Periods etc, getting the FUTURE date correct is vital so that you'll not lose billions or be sued by the billions.

So what's this have to do with you setting backdate of your own PC again? Nothing. It's the people who actually write time-critical systems that matters because their code affects billions of dollars.

This is where you're showing your incompetency in understanding this technical thingies. See, you fail AGAIN and AGAIN to see the effect of such date anomaly. Your utter craps precede your intelligence (if you have any).


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


Of course Captain Obvious, we are talking about C and its data structure. time_t is never a VisualBasic.Net material the last time I checked. You are funny when you're extremely mad. Hey, you snot is dripping too! Hahaha Very Happy


Quote:
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



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.
Post 10 Jul 2017, 18:35
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 567
Critical app does not equal financial app. Scientific critical apps which use dates already use a different system, with much finer granularity (the unix time is limited to seconds of precision only), probably depending on the database software.

Furthermore I've already stated that it is only an issue for apps relying on dates. If some financial systems indeed ran into this issue, they've already solved it LONG ago by switching to 1) patched version of the OS 2) a different OS 3) different software. I mean, you run into a limitation of your current system, you see it can't do it, you replace it. It's simple.

Remind me what the fuck has all this to do with Fasm? Show me financial software written in Fasm suffering from this bug. Hey, you're the one who said you weren't talking about Fasm, yet you asked T.G. himself about it? Don't backtrack on your words.

Of course it's good to patch it if possible, but it doesn't change the fact it's not nasty, period.


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

Indeed, and too bad I was referring to computers crashing hyped up by the media, in my very first post. (as in doomsday situation)


system error wrote:
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.

When an application gets compiled, it receives instructions based on the type, yes. However, those instructions are the EXACT SAME INSTRUCTIONS for most arithmetic instructions in 2s complement. There is literally no difference. That's the whole point of 2s complement, and again, why do I have to repeat myself?

If you change your stupid integer to unsigned from signed and do any basic arithmetic operation (except comparing them!), nothing will change in the generated code. Because there is no difference there, and we were talking abut subtraction.

This applies to any architecture using 2s complement. x86 happens to be one of them, like almost every single relevant architecture out there.

This is why I asked you to show me an architecture without 2s complement. You don't get it do you? In an architecture with 2s complement, there is literally no difference between signed and unsigned in basic arithmetic operations. Not a single bit of difference in instruction encodings. Your "type" doesn't matter.

Type matters when you use the following operators in C and it's when they generate different instructions (for a 2s complement architecture):

<, <=, >, >=, >>

And of course, division and long multiplication (long meaning you do a multiply of two values and use a result twice as big, which C doesn't do by default btw), but who the fuck divides/multiplies dates? What sense does it make to multiply them?

Case in point: for subtraction, whether your C type is signed or unsigned, the compiler will generate the exact same code. It is required to, by design of the architecture. So the code will only be different for subtraction if the architecture doesn't use 2s complement. Show me one.
Post 10 Jul 2017, 20:15
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 522

Quote:
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.

It is not the machine binaries that is of concern here dumbob. As I told you before, it's about C's int type (as in C material!). It's how C's int parse or interpret it that counts because it is a TYPE (see, I have to repeat myself TWICE every time to make you understand all these technical things).

Of course in ASM point of view, 2147483647 + 1 = 2147483648

BUUUUTTT....

in 32-bit C's int TYPE, 2147483647 + 1 is interpreted as -2147483648

See the problem here, dumbob? If you don't, try running this simple C code;


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;
}



Of course I can provide my own patch but that works only for my code and my system for that particular problem above. Other that than, it will quickly hit a compatibility wall somewhere if I were to distribute it somewhere else. So whether you like it or not, you'll have to do it from the kernel and rely on the kernel developers to deal with the patches, hoping that everybody else update their kernel.

You're a complete waste of time. Go read a book or something.
Post 10 Jul 2017, 21:06
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 567
That's not true. 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. Comparison operators generate different instructions depending on the signedness -- you can of course typecast them when comparing if you want to force a certain operation. (a common trick in low level generic C++ code with templated types btw)

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 -- note that printf doesn't know anything about the signedness of the variable by itself, since it can't. It knows it by you explicitly telling it what type to interpret that variable as via the % format specifiers. (e.g. %d is signed int, %u is unsigned, and the time formats is based on signed properties). If you use %u on a signed value it will print it as unsigned.

However this has nothing to do with subtraction anyway. Of course you are right that it will overflow if you want to print absolute value -- that's an absolute fact, nobody disputed it man! I was referring to systems using "delta time" to know how much time elapsed (e.g. GPS, even though it doesn't rely on this system because it's too imprecise, but just as an example)

Go and subtract two dates 10 years apart or whatever other value (as long as it fits within the epoch). And then print that value (after subtraction). It doesn't matter what the dates are originally (one can be high the other overflown). You'll be amazed. They can be for example 2036-2026 = 10 years. Right?

But now try to give it as input 2036+10 and 2026+10. First one will overflow, and guess what? Even with signed overflow, the result is still correct which is 10 years after subtraction -- the printf function will never know it even overflowed in the first place. All it knows is that 10 years passed.


Case in point: all embedded systems that rely on delta time (i.e. how much time elapsed) will work perfectly fine with zero patches, because of the magic of 2s complement. (literally the same instructions and same code). Financial systems won't, but those systems have way bigger problems than just the stupid kernel reporting bad date -- they need databases to be able to store future dates as well, and they're not exactly "embedded" in my view.

When I think of embedded, I think of low-power devices. For a practical example, my DSLR camera has the wrong date because I didn't power it on for awhile and forgot to put batteries. Guess what? I didn't even bother to set it back, even if date is wrong, because it doesn't matter. Who cares of file timestamps? Especially since I convert them from RAW to jpeg or whatever when I transfer them and thus they will have new timestamps anyway.

Ergo my verdict is that it's a minor problem, because for those systems that it is indeed a problem (e.g. financial) it doesn't exist since it's been fixed for ages. (like you said they need to store future dates as well)
Post 10 Jul 2017, 22:13
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 522

Quote:
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.



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.


Quote:
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.



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().

So yes, SIGN-NESS MATTERS in time/date critical library.

I'm not interested in addressing your extended craps.
Post 10 Jul 2017, 23:07
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 567

system error wrote:
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.

The signedness of the type doesn't matter one bit to the function you pass it. Only its value, whether it came from unsigned, signed, or float even. The function doesn't even know what variable you passed it as, even less its type. Basic computer science for a statically typed language? wtf man Confused

What it does is it treats that value as signed (or whatever), no matter what you pass it. You can pass it an unsigned value too. The "type" does not exist (beyond compile-time checks and warnings) as far as the function is concerned: all the function does is it treats it as signed a specific amount of bytes.

Heck you can even call the function from a totally different language (or even asm). There's no such thing as "type" in compiled code (which ultimately is what needs to get "patched" right?), only when checking compilation and when deciding what operations to use (signed or unsigned comparison operators, mul/divide and right shifts).

The function is already generated though. The "type" of the function parameters matter when compiling the function itself to know what instructions to generate, not when calling the function which is already compiled.

There's no such thing as "calling a function with a signed value". It's just "calling a function which INTERPRETS the integer value as signed". You pass it integers, it's up to the function's code to decide whether they are signed or unsigned. In this case, that function is printf and you control how to treat them with the % format specifiers. Of course other functions also accept signed values, but that's their own fault.


system error wrote:
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().

EDIT: nevermind, mixed up functions.

No, what the function does is it assumes that the pointed-to data is signed. Just like printf does. This has nothing to do with your type though. You can pass it unsigned value and it will still freak out if it's too large. Nothing to do with "C stuff" or "asm" or whatever. It's just the function -- you can write your damn own function to accept unsigned values if you want. That function isn't even special in terms of requiring kernel privileges.

However, like I said before, I was talking about the difference between two time periods -- time deltas. Pass that to localtime and it will never be "negative". Regardless if it overflowed before the subtraction.

Of course you are right that it won't be able to successfully print the absolute time, I never denied this, so why fixate on it? But "absolute time" is, in most cases, not needed and pointless. Only in record-keeping (financial transactions) but in that case, they likely use custom databases instead of relying on such functions.

BTW, I'm pretty sure the code doesn't freeze, even with invalid values, that would be very poor design and in fact make no sense at all. To "freeze" it would need special code to do so on purpose. That's retarded. (I mean localtime). If you're trying to exaggerate, then you just proved my point about the media bullshitting and hyping it to unreasonable levels, so thanks?

Instead, it will report the wrong date (1901 instead of 2039 or whatever), which is a minor problem, deal with it.


Look at this code:

Code:
sub eaxedx

You can call eax with -2147483639 (try it, that is 2147483647+10 so it overflowed by 10 since we assume signed) and edx with 2147483647, and guess what the result will be? 10. Where the fuck does signedness matter in subtraction?

And that's the instruction any compiler will generate regardless of the type's signedness.
Post 10 Jul 2017, 23:24
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 522

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



So what's the output of the last two "now"s then? Why they freeze? Is it because of your incompetency in interpreting the simple facts that C's time functions take only positive integers of a signed value? Should I tell your employer about this lil secret? ;D
Post 11 Jul 2017, 00:05
View user's profile Send private message Reply with quote
Furs



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

localtime treats it as signed, so 0x80000000 is -2147483648 for it. Ever tried to pass it an unsigned 2147483648? Yeah, you get a "negative" output (same as -2147483648 since it's the exact same number), hence the type of what you pass does not matter, only what the function expects. All the function sees (literally!) is the bit value 0x80000000 -- it treats it as signed, but it doesn't know (or care) the type of what you passed it. If you pass it uint32_t of value 0x80000000, you get the same thing (negative output), even though uint32_t is unsigned and its number is definitely positive.

Whatever, I'm not interested in discussion basic things further especially about C/C++ in an unrelated thread that you clearly lack understanding of (if you're so confused about C's static typing, I'd hate you to even attempt to learn C++'s peculiarities like rvalue references and the like). This has nothing to do with this, anyway.


And btw, the only thing that is actually interesting is your "freeze" claim. Does it actually freeze on an unpatched system, like do you have some proof of that??!? I tried on a so-called "patched" system (as you claimed!) and setting dates to earlier than 1970 (which is negative, even if time64_t is used I believe?) and nothing happened. So it's your turn to prove that it actually freezes on "negative dates" on a "unpatched" system.

If not, you're hyping the bullshit up just like the media with freezes and crashes. Freezing would mean the application cannot handle dates earlier than 1970, which implies flawed application design (those dates are "negative" since 1970 is considered the centerpoint or "zero"). If you can't handle negative numbers while using a signed type, the application is trash.

I guess you'd make a great journalist with clickbait titles, though.

I mean, not even financial apps will "crash" or "freeze" on negative dates, they'd simply report the wrong date (which is a large problem there though), but that has more to do with the database's ability to store them than anything else.

If you ask me why I'm interested in your "freeze" claim, it's because that's exactly what I said in my first post with overblown bullshit from the media. So no, that's precisely what the topic was, you drifted way off topic with C "stuff", not me.
Post 11 Jul 2017, 11:59
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 522

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



You don't have to tell me that. I've written them in code above. Did you really have to repeat that? Are you really that dumb to separate the idea of signed and unsigned integers? XD

I did not ask for you crappy advice on what's is machine binaries. You don't have to write that long to explain your own incompetency.

My test code was actually on Windows (hence the "bug.exe" output). It freezes on Windows and it shows incorrect date when compiled on Linux. In both cases, anything that goes beyond largest positive signed produce buggy results.

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.

If you still can't understand this simple fact, I suggest you quit your programming job altogether because you're dangerously incompetent, and that incompetency + your big mouth may cost others a lot in not so distant future.


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



Drifted off topic? This Y2038 bug is very C-specific, dumbob! OMG, does it have to be that obvious? Very Happy
Post 11 Jul 2017, 13:11
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 567
The Y2038 bug has nothing to do with C, unless you think only C has integer overflows. You're literally retarded. The entire thing is the very definition of signed integer overflow. See: https://en.wikipedia.org/wiki/Integer_overflow (with certain CPU flags you can even precisely detect when it happens, if you want that, of course). 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.


system error wrote:
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.

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). Of course there's many bugs with integer overflows and those can be a real problem. But for dates it's usually just the wrong date, big deal?

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.

(read the Examples in the wiki, they show you that most affected by this don't use Unix time because they need more precision than just seconds, and they can be reset manually as a workaround, same as moving the clock back by 10 years for example; inaccurate dates are not a nasty problem)
Post 11 Jul 2017, 13:40
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 522

Quote:
The Y2038 bug has nothing to do with C



Integer overflow also occurs in field of medicine, finance, rocket science. It's too broad of a statement. We are talking about a kernel problem, which relies on C faulty data structure. This bug is also called Unix Millenium Bug

Nobody in this world would talk about this bug without mentioning C. Only incompetent idiots would talk about Java data structure when mentioning Y2038 bug.


Quote:
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.

Save this utter craps for your dog. Not interested in garbage.



Quote:
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).



My Windows (Win10 64-bit) system freezes. My Linux shows negative date. Which part of "don't feed negative values to time_t" that you didn't not understand?

Why would I lie? I am not the one with big incompetency issue, here. Very Happy


Quote:
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.



Dates are not minor stuff. Your daily compounded savings, with 20 year maturity, would be extended to 100 years, beyond EPOCH times, if YOU happened to be the programmer. I know I would not hire you if I was one of the potential employers.

You're technically incompetent. That's the conclusion.
Post 11 Jul 2017, 14:17
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 567

system error wrote:
Integer overflow also occurs in field of medicine, finance, rocket science.

Man, I'm done here, you always say such ridiculous shit it's hard to even take you seriously. The first few words of the wiki: In computer programming, an integer overflow occurs when an arithmetic operation [...]

There's no such thing as integer overflow in medicine since it doesn't even have integers (the fuck?) nor finance (it's only the computers it relies on that do, so yes, computer programming).

It's not too broad of a statement, you're just grasping at straws and don't understand a single thing about anything you say but parrot articles online and use buzzwords to sound cool, like "C structure" (lol) when you make absolutely zero sense since it has nothing whatsoever to do with any structure.

time_t is not even a structure, it's a fucking typedef, a type alias to a signed 32-bit integer in this case. You're delusional. Not to mention it has nothing whatsoever to do with C, at all, it's simply a 32-bit signed integer overflow, but you'd know that if you actually read and understood the link.

If you think about localtime, then you don't need that stupid function, because internally you store the 32-bit number or whatever in the database (yes, again that word, since I use words properly unlike you Wink) -- you operate on that number time_t or whatever, not on the retarded struct from localtime which is for display only just like printf. So localtime is irrelevant, only the get time function matters. If you do calculations with future dates (as you said with finance), then who stops you from converting the time_t to uint64_t and never overflow for any future dates? Zero change in the kernel required, until 2038 ofc -- databases don't store your retarded localtime struct, they need to be efficient and not even based on a local time (what if they get backed up to a different zone with a different timezone setting?). Databases keep records in finance, and they store an absolute universal time reference, like time_t, not bloated (and not absolute since it's local by definition) localtime.

Plus "negative date" shows why you lie (your words). 1970 is "zero" so anything negative is before 1970, so 1969 is a negative number? Since when? That's what time_t would represent. You now know how to spot a bad liar. Wink

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.
Post 11 Jul 2017, 18:13
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 522

Furs wrote:
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. All I did was to bitchslap you with a simple C code to show people your incompetency in appreciating the differences between signed and unsigned integer. How's your face right now? Still burning? Hahaha Very Happy
Post 11 Jul 2017, 19:22
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 567

system error wrote:
I don't need wiki.

Of course you don't. You're a special specimen on the internet.

Oh, here's the wiki page for Year 2038 problem also known as "Unix Millennium Bug" by association (this is a literal phrase from the wiki page!). You called it that way, right? So it fits with what you're talking about.

https://en.wikipedia.org/wiki/Year_2038_problem#Vulnerable_systems

Here's a relevant paragraph with emphasis on mine:


wikipedia wrote:
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).

Time difference = delta = twos complement magic which I've been saying all along.

Notice how nowhere does it state any of your stupid "localtime" structures since only braindead monkeys would even think of that instead of time_t (but it does reference time_t multiple times).

Please kid, stop wasting people's time who know what they're talking about and embarrassing yourself in the process.

Literally everything I have said is on there (incl. the databases!), so stop deluding yourself. You're like a clown to any serious programmer. The sooner you accepts facts, the better for everyone including yourself (ignorance is NOT bliss, it's a disease, FYI)
Post 11 Jul 2017, 23:20
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.