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

301–310 of 419 posts

Re: It Can Happen to You

#301

Post by tomck »

scaramanga wrote: post #35

"it will open a 97 MB binary STL file in about 165 milliseconds flat, on a 2013 Macbook Pro. This is blinding fast." This actually sounds incredibly slow, that's nearly 1/5th of an entire second. What can it possibly be doing? :) In case anyone else was wondering, I followed the link and clicked the description and this is actually based on the time to the first frame being rendered - not just the time to load the fi…

Is that really that slow? idk how they even read the file in that amount of time, my drive is only about 125MB/s

Re: It Can Happen to You

#302

Post by bovermyer »

The actual moral of the story here is twofold.

1. Don't assume you would never make _that_ mistake, and

2. Be understanding and kind to those who do.

No one died as a result of this error. There is zero reason to be hostile to the developers.

Re: It Can Happen to You

#303

Post by thaumasiotes »

TeMPOraL wrote: post #297
thaumasiotes wrote: post #269

Earlier quoted context omitted.

Well, no, the whole point of this discussion is that solving the second problem means the first problem never comes up. And this isn't exactly some exotic approach; how often do you think people write Hashes in Ruby where the keys they use are all symbols? It's so common that there's dedicated syntax for it.

It's as old as Lisp, but there's a reason symbols exist separately from strings - they're used differently. Strings are frequently transformed, symbols almost never are. String are frequently taken from end-user input, symbols very rarely. Strings sometimes are very large, symbol names are almost universally very short. The problem is, interning is an expensive operation. It means adding to an ever growing database o…

I definitely agree that uninterned strings are important. All I'm really trying to say down here is that there are many cases where you have a hash table which uses strings as keys (as an implementation detail), when (conceptually) it wants to be using symbols.

(And on a less fundamental level, the particular Java String class is less string-like and more symbol-like than most string types, and this appears to have been done intentionally.)

Re: It Can Happen to You

#304

Post by JdeBP »

dominicl wrote: post #263
formerly_proven wrote: post #261

Earlier quoted context omitted.

I don't know if it is required to, but there doesn't really seem to be an upper bound to what glibc's scanf will eat for a %f (e.g. a gigabyte of zeroes followed by "1.5" will still be parsed as 1.5), so for that implementation there certainly isn't a trivial upper bound for the amount of input read and processed that is done for %f, like you would perhaps expect. Yet another reason to not stringify floats. Just use…

But why do strlen() at all? And why are all platforms (Linux, Windows, MacOS) seemingly doing that? I think you're right that there is no upper bound but it shouldn't be necessary to do a full strlen() if you're instead scanning incremental. You could go char by char until the pattern '%f' is fullfilled and then return. That would solve the issue on it's root -- and who know how many programs would suddenly get faste…

See https://news.ycombinator.com/item?id=26298300 . The alternative implementation technique that already exists in some C implementations is not to use nonce FILE objects at all.

Re: It Can Happen to You

#305

Post by le-mark »

bovermyer wrote: post #302

The actual moral of the story here is twofold. 1. Don't assume you would never make _that_ mistake, and 2. Be understanding and kind to those who do. No one died as a result of this error. There is zero reason to be hostile to the developers.

I propose a third moral, don’t use scanf when a dfa would suffice!

Re: It Can Happen to You

#306

Post by quelsolaar »

kaba0 wrote: post #209
quelsolaar wrote: post #142

Earlier quoted context omitted.

Wouldn't this be an argument to go in the opposit direction? If you are using high level functionality that you dont know the implementation details of, you are running the risk of unintended consequences. I am a C programmer who have implemented string to number parsing for this very reason. I know exactly what it does and how fast it is. If you do use code you didn't write, The chance of a standard library being po…

I think it goes both ways in that you either go full low level and write yourself everything (for questionable benefits), or you use a (possibly higher level) language with sane standard library, but the important thing is the quality of said library.

I find that writing everything yourself, especially simple things like a text2inteeger parser, is very valuable because it takes very little time and it levels up your understanding of the system. I'm starting to believe that you rarely understand something until you have implemented it. Therefor implementation is the best way to learn.

Re: It Can Happen to You

#307

Post by jameshart »

virgilp wrote: post #173
lostcolony wrote: post #146

Earlier quoted context omitted.

Fair point; I'm confusing my terminology. Analogy and realization still holds.

Also, already sorted data.. in reverse order. If it's already sorted in the right order, quicksort takes linear time. This is an important difference - data you use might indeed often be appropriately sorted, but in practice will seldom be sorted in reverse order.

On the contrary: very common UI pattern to have a data grid that sorts by a particular column when you click the header, then reverses that sort order when you click the header again. So for a user to sort by date, descending, they click the header, causing an ascending sort, then click it again, causing a descending one.

Often such a grid will be quite well abstracted from its data source - it might be executing a remote query to return data in the new order every time - but I bet there are some examples out there that are backed by a local dataset and carry out an actual sort operation when you hit the header... and fall into a quicksort worst case if the user clicks the same header twice in a row.

Re: It Can Happen to You

#309

Post by eru »

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.

You joke, but there's actually lots of work going on into what techniques will definitely NOT be enough to settle P=NP.

(I find it pretty exciting, that this kind of negative result is possible. Ain't mathematics wonderful?)

Re: It Can Happen to You

#310

Post by JdeBP »

tux3 wrote: post #15

The moral of the story, as far as I'm concerned: do NOT parse strings in C! Use a library, prefferably in a higher-level language. C string handling is a mess of viciously surprising APIs, juggling those particular footguns is almost certainly not your least bad option.

Like RapidYAML, written in C++, which had the bug until 2020? (-:

* https://news.ycombinator.com/item?id=26302744

"Use a library" is observably not a panacea in practice.

Post reply on HN