That doesn't make sense. If new < old cant happen there is no need to make a comparison. Stack corruption? Nah, its a counter not an index or pointer or it would fail sooner. But then what is the failure? IDK
Assuming new > old doesn't mean you actually make the comparison, but rather that the code is written with the belief that new > old. This code behaves correctly under this assumption, but might be doing something very bad that leads to a crash if the new < old.
An actual analysis would be needed to understand the actual cause of the crash.
Um, there are the cases new == old and new > old. And all the more specific cases new == old + n. I haven’t seen the code so this is just speculation, but there are plenty of ways how an unexpected, "can never happen" comparison result causes immediate UB because there’s no execution path to handle it, causing garbage to be returned from a function (and if that garbage was supposed to be a pointer, well…) or even execution never hitting a `ret` and just proceeding to execute whatever is next in memory.
Another super easy way to enter UB land by assuming an integer is nonnegative is array indexing.
int foo[5] = { … }
foo[i % 5] = bar;
Everything is fine as long as i isn’t negative. But if it is… (note that negative % positive == negative in C)
The error states that the window can't be created. It might be the problem with parameters to the window creation function (that should not depend on game state), or maybe the system is out of memory. Resources allocated in memory are never cleaned up because cleanup time overflows?
Doom4CE (this port) was based on WinDoom, which only creates the program window once at startup, then switches the graphical mode, and proceeds to draw on screen independently, processing the keyboard and mouse input messages. I'm not sure, but maybe Windows CE memory management forced the programmer to drop everything and start from scratch at the load of each level? Then why do we see the old window?
There are various 32 bit integer counters in Doom code. I find it quite strange that the author neither names the specific one, nor what it does, nor tries to debug what happens by simply initialising it with some big value.
Moreover, 2^32 divided by 60 frames per second, then by 60 seconds, 60 minutes, 24 hours, 30 days, and 12 months gives us a little less than 2.5 years. However, Doom gameplay tick (or “tic”), on which everything else is based, famously happens only 35 times a second, and is detached from frame rendering rate on both systems that are too slow (many computers at the time of release), or too fast (most systems that appeared afterwards). 2^32 divided by 35, 60 seconds, etc. gives us about 4 years until overflow.
Would be hilarious if it really is such an easy mistake.
How many hours did you put into this app? How much money have you made from it?
If it really can be written in a couple days (with or without AI) I would say you're lucky to make what? A few thousand dollars? (I'm assuming a top 100 app that got talked about sold at least 1000 copies for at least a few dollars each)
> I'm assuming a top 100 app that got talked about sold at least 1000 copies for at least a few dollars each
No, this is a vast overestimate for top 100 paid utilities in the Mac App Store. And there's no actual evidence I can find that the app was "talked about" anywhere.
Yeah, I just wanted to get an idea of just how much money he was making.
If he was averaging a dollar a week since release (which I was once told is above average for mac tools) it seems unlikely that cloners would continue cloning his app as long as he kept maintaining the original.
> If he was averaging a dollar a week since release (which I was once told is above average for mac tools) it seems unlikely that cloners would continue cloning his app as long as he kept maintaining the original.
With every comment the developer makes, it becomes more and more apparent to me that the developer's story is a lie, and this HN submission was just a publicity stunt, perhaps in a desperate attempt to escape from App Store oblivion. There are no links or concrete proof given of any of the developer's claims. Unfortunately, the audience appears to have taken the story for granted with no skepticism.
Yeah, screw those old people with their houses! We should deliberately kill them off so that we can have cheaper houses! But please, don't let the next generation do that to us when housing turns out to be expensive for them too!
I have yet to see my government subsidise dangerous recreations based on a cost benefit analysis.
I think government costs for a retiree are about NZD27000 a year.
A government should be subsidising a good deadly recreation for say NZD10000 a year. Assume expected life remaining is 10 years, assume recreation has a 10% chance of clean death, assume low chance of expensive ongoing chronic outcomes.
Maybe a better way would be to allow people to gamble with their lives to win a few tens of thousands (need to balance costs against expected savings). Pay out to winners, but saves the government their expected lifetime of expenses for the losers. Let the old and unhappy roll-the-dice and the winners get to live it up a little . . .
There are over 30 strains of HPV with just 2 causing the majority of cancers. So sure, most people may have had some strain of it, but that's not really relevant unless immunity is broad across strains.
Can you handle parking structures? I heard a lot of the autonomous cars were using 2D maps and couldn't handle multiple levels. Haha! This was just a year or two ago.
Google maps has been able to figure out parking structures for me recently. Not sure what technology is involved (gps isn't great for vertical) but it's clearly possible.
Google has been collecting data on building interiors for several years now. Not just parking structures. This data is currently used in streetview. Google's geospatial data is unequaled and maybe a bigger advantage than is readily visible.
Do they need a "map" of a parking tower though, just like how humans don't exactly need Google Maps inside of one? I feel like this is something self driving + vision (exit signs and arrows) can handle
>> though in my personal experience I saw far more of the Highlanders than the custom robotaxis and all of them seemed to have a driver behind the wheel.
The robotaxis have a steering wheel? I thought they had campfire seating with 2 backward facing seats.
If by robotaxi you mean the vehicles used in the tesla test in Austin and now in the bay area, they are just regular model y with an emergency "stop so you don't kill me button" on the right side. They have a special version of the software that is unreleased. The current model Y's / "robotaxi" have all the regular hardware, including pedals and steering wheel and sensors. If you search, you can even find cases during the Austin Texas where the safety drier gets into the driver seat in a few situations.
We don't really know what a special robotaxi hardware would look like.
>> Through the years, imec has made considerable progress in assessing, understanding, and modeling reliability failure, paving the way to building reliable IGZO transistors with a target lifetime of five years
Five year lifetime isn't getting anywhere near my setup. Also notably absent was anything about read or write times. It sounded promising all the way up to that last paragraph.
The read and write times are apparently in the ~10ns range which is within the allowable range for DRAM (you'll have another 50-100 from the connectivity anyway)
It would be a waste to use this to just make DIMMs. It's only transistors, like SRAM cells, so you can efficiently fab them on the same process technology and the same dies as your logic.
Then again, there is wear, so either you accept a level of performance degeneration (dynamic capacity cache?) or you go to DIMMs anyway servicability.
