Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It Can Happen to You

mattkeeter.com

Post reply on HN
Print view View original

391–400 of 419 posts

Re: It Can Happen to You

#391

Post by dom96 »

c-c-c-c-c wrote: post #275
tpetry wrote: post #188

I don‘t get the heat of this topic. Yes they wrote some very slow code because it‘s easy to shoot in your foot with scanf. It‘s nothing new that most software could be heavily optimized by just benchmarking slow parts. There is no reason for this shit storm than to feel better than other developers. The real problem is that they shipped a game with a loading screen which is taking minutes and not looking whether they…

Thing is that they didnt ship it that way. Back when it came out the loading screens were "fast". Things just grew out of proportion with the exponential increase of new items in the online mode.

The loading times for GTAV have always been horrible.

Re: It Can Happen to You

#392

Post by froh »

abetlen wrote: post #385
froh wrote: post #380

Earlier quoted context omitted.

scanf and printf have complementary format specifiers, which can make maintaining serialization and parsing of regular data a breeze... the proper remedy is to simply wrap the string to parse with fmemopen(3), which makes the temporary FILE object explicit and persistent for the whole parse, and needs just one strlen call. https://news.ycombinator.com/item?id=26343149

Cool trick, thanks for sharing. I don't get why there isn't a suitable snscanf function that takes the buffer length as an argument and returns the number of bytes parsed?

fmemopen takes the buffer length, and there is no need to have the buffer \0 terminated, so instead of strlen you can also just give the buffer size.

The number of bytes parsed can be fetched with the scanf %n format specifier.

Re: It Can Happen to You

#393

Post by kaba0 »

akkartik wrote: post #384
kaba0 wrote: post #379

Earlier quoted context omitted.

My question is regarding why would a single language codebase be easier to comprehend/have fewer bugs, security holes? In terms of a single program it makes sense, but I seldom read the source code of a library for example I depend on - if it has a good public API, it could be written in anything for all I care. Not trying to dismiss the idea at all, just I don’t yet see “the light”, so to say.

Yeah, these are good questions and to be fair your questions are shared by many. My basic worldview is that we need to have 100-1000x more people reading and auditing open source. The original value of open source was in the ability of people to read the source. If we don't use that ability then we don't really get the benefit. The world today focuses on APIs and ignores implementation. I would argue that's the bigge…

Thanks for the answer! I totally agree on the not enough people read source code part — unfortunately I believe it is not only a language “barrier” thing. I mean, even in a language I know by heart, I probably could not make sense of some complex part of the linux kernel, because I lack both the underlying technical knowledge on some hardware interface, or the context of the code. And especially this latter can not be overcome with only code with good comments. It needs good documentation, which should give a basic understanding, and on top of it we can build the code for the fine detail. Of course it is a noble goal to try to decrease the surface area of the required knowledge, so props to you!

What’s your proposed solution to the problem with low and high level languages? Is the level 3 language a higher level one? Because I’n not sure there could exist a one language to rule them all, because of the inherent difference between the two domains.

Re: It Can Happen to You

#394

Post by akkartik »

kaba0 wrote: post #393
akkartik wrote: post #384

Earlier quoted context omitted.

Yeah, these are good questions and to be fair your questions are shared by many. My basic worldview is that we need to have 100-1000x more people reading and auditing open source. The original value of open source was in the ability of people to read the source. If we don't use that ability then we don't really get the benefit. The world today focuses on APIs and ignores implementation. I would argue that's the bigge…

Thanks for the answer! I totally agree on the not enough people read source code part — unfortunately I believe it is not only a language “barrier” thing. I mean, even in a language I know by heart, I probably could not make sense of some complex part of the linux kernel, because I lack both the underlying technical knowledge on some hardware interface, or the context of the code. And especially this latter can not b…

Yeah, level 3 will be a HLL. It just doesn't matter too much which one it is, or that it "rules them all". A single reasonably high-level language X is in practice superior to a basket of high-level languages, even if some of the languages in the basket are individually higher-level than X.

You're absolutely right that languages are only part of the problem. Beyond the language choice, Mu provides guardrails to help you pick up the underlying technical knowledge by just trying things and seeing informative error messages (often failing tests) in response. That's the hope, anyway.

Right now the first HLL is still in progress. I spent some time with a postfix-based language before changing my mind. Now I'm working on a Lisp-based HLL. So I'm not dogmatic about what the HLL should be, and in time there will probably be multiple options in separate forks/repos.

Re: It Can Happen to You

#395

Post by koalahedron »

ctoth wrote: post #207
ineedasername wrote: post #101

Earlier quoted context omitted.

That's actually a very simple one. Just run a regex on "P != NP" to remove the "!" and you're good to go.

Seriously the most I have laughed in like 6 months. Which probably says a lot more about me than this joke. I know that jokes aren't really welcome on HN, and I generally really like this policy. But just had to mention this was just ... what I needed to read right now.

> I know that jokes aren't really welcome on HN

IMO, while I really don't come to HN to find dial-a-joke, or joke-of-the-day, I think some humor is essential in modern life.

Since we're talking about Matt Keeter, you will find he has a great sense of humor if you read his website or interact with him. Some of his jokes are ROTFL funny, but subtle.

Re: It Can Happen to You

#396

Post by stainforth »

johnfn wrote: post #32

Loving the progression here. Tomorrow, someone’s going to reduce the boot times of macOS by 90% by the same principle. A week from now, someone will prove P=NP because all the problems we thought were NP were just running strlen() on the whole input.

Next Hacktober should offer a free t-shirt to anyone who goes out and issues a PR to a repo containing sscanf

Re: It Can Happen to You

#397

Post by randyrand »

SomeCallMeTim wrote: post #359
simias wrote: post #320

I think the really embarrassing part for Rockstar is that they didn't bother to investigate what took 5+ minutes to load in their star product, a simple profiling would've made the issue obvious. So either they knew and they didn't care, or they didn't know and they didn't care. That being said both for GTA and for TFA the issue is a very similar sscanf call: sscanf(data, "%f", &f); I already posted a similar comment…

Agreed. My first instinct was the same: *scanf is never the right tool for pretty much any job. I learned this 20+ years ago. As far as I'm concerned it should have been considered deprecated along with gets; it was considered dangerous in the early 90s and probably before. Not sure why people are still using it in the 2000s+.

why?

Re: It Can Happen to You

#398

Post by moonchild »

JdeBP wrote: post #315
desertrider12 wrote: post #130

Earlier quoted context omitted.

Reading this article was a surprise for me, I didn't know of this issue at all. But this is pretty ridiculous. If it's possible to write scanf, which matches chars from a stream, why can't sscanf just do the exact same thing but check for '\0' rather than EOF...

It can, and the people who only check a few well-known open source C library implementations miss that there is quite a range of other C library implementations out there that do this very thing , from P.J. Plauger's through OpenWatcom's and Tru64 Unix's to mine. (-: * https://news.ycombinator.com/item?id=26300532

I don't know what you mean by that. I pointed out two libcs that do exactly that (that was what I meant by ‘the sensible, simple implementation’; perhaps that wasn't clear enough?) as well as multiple other approaches that also result in correct performance. And the managarm and sortix libcs (for instance) are hardly well known.

Re: It Can Happen to You

#399

Post by ummonk »

thaumasiotes wrote: post #342
SilasX wrote: post #329

Earlier quoted context omitted.

Here, the relevant key is the output of the hash function though -- that's what you need to increase in order to ensure you can reach all buckets. And that (k) must increase with the table size. So it is not constant and depends on n (table size). Earlier discussion: https://news.ycombinator.com/item?id=9807739

I remember a proof in CLRS which first developed a function that was bounded above by 5 for all conceivable input ("a very quickly-growing function and its very slowly-growing inverse"), and then substituted the constant 4 or 5 into a complexity calculation in place of that function, giving a result which was "only" correct for all conceivable input. The same approach applies to key length requirements for hash table…

By that logic, any O(logN) factor is simply O(1). That O(NlogN) sort algorithm should just be considered O(N) for all practical purposes.

Re: It Can Happen to You

#400

Post by ummonk »

SilasX wrote: post #329
thaumasiotes wrote: post #318

Earlier quoted context omitted.

> Everything is O(1) if N is constant, including log(N), N^2, 2^N, N!, etc. Not even close. 2^k is not O(1) by virtue of N being constant. Only 2^N. This has been covered above. It is more common to consider the complexity of hash table operations in terms of the number of operations, or the size of the table; the size of the key is very often constant. These are different variables; the constant size of the key does…

Here, the relevant key is the output of the hash function though -- that's what you need to increase in order to ensure you can reach all buckets. And that (k) must increase with the table size. So it is not constant and depends on n (table size). Earlier discussion: https://news.ycombinator.com/item?id=9807739

Incidentally, the person replying to you in that thread incorrectly stated that comparison is O(logN) on the number of bits. The most common comparison function, lexicographic comparison, is actually O(1) average case given random inputs of arbitrary length.
Post reply on HN