311–315 of 315 posts
Earlier quoted context omitted.
The constant rust evangelism on this site is such a turn off from actually wanting to use the language.
While they did mention rust, the actual suggestion was "functional programming and immutability", which to me suggests several other languages first and makes it not really rust evangelism.
Earlier quoted context omitted.
I once updated a little shy of 1mloc of Perl 5.8 code to run on Perl 5.32 (ish). There were, overall, remarkably few issues that cropped up. One of these issues (that showed itself a few times) was more or less exactly this: the iteration order through a hash is not defined. It has never been defined, but in Perl 5.8 it was consistent: for the same insertion order of the same set of keys, a hash would always iterate…
At booking.com? :)
It has always been too easy to read & write beyond the stack. This should fail, plain and simple. Mitigations exist - ASLR, NX pages, stack-smashing protection etc. but nothing comprehensively stops reads of stale data beyond the stack. Thought experiment for a moment. What if the hardware ensures the unused part of a stack region cannot be read or written. There are many ways to skin this cat, here’s one based aroun…
This bug wasn't caused by a read beyond the current bounds of the stack, but a stale value from a prior call to the same function at the exact same location on the stack. Buffer-overflow protections like you describe wouldn't help here.
I’m proposing the memory of the fresh stack frame initially reads as zeroes until written to.
> all these findings prove that the bug is NOT an issue with Windows 11 24H2, as things like the way the stack is used by internal WinAPI functions are not contractual and they may change at any time, with no prior notice. This reminds me of an excellent article I read a while back, the gist of it was that, given sufficient success, there's no such thing as a private API.
Could you please find this article and link it here. I'm curious about the arguments.
Earlier quoted context omitted.
IIRC the whole parsing performance issue was because the original code was written for the SP campaign of GTA5 that only had a handful of objects to parse data for. That was barely a blip in terms of performance impact and AFAIK was written years before GTAOnline was made (where it became an issue - and even then only became an issue much after GTAOnline was first made). Writing some simple code that works with the d…
Are you actually arguing that using a JSON parser for JSON-formatted data is a premature optimization? The solution here was to use a different format, not a somewhat-JSON-compatible hacked together parser.
The premature optimization would be trying to optimize that piece of code without that being necessary given what the code was meant to do.