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

111–120 of 419 posts

Re: It Can Happen to You

#111

Post by adamzegelin »

eternalban wrote: post #92
rudedogg wrote: post #38

Earlier quoted context omitted.

Funny, the ergonomics of the Swift string API are so bad that I've started learning a lower level language for parsing, etc. Here's my favorite WTF: https://christiantietze.de/posts/2020/01/string-index-offset...

You can fault the docs but what's the problem with the API? Why should you be surprised that accessing a collection with 'nil' index is a runtime error? What else could it be? A simple fix in the doc seems to solve the confusion: "Returns an index that is the specified distance from the given index, unless that distance is beyond a given limiting index [in which case it returns nil]". It does say "returns an index ..…

The problem is that `s.index` with an `offset` equal to `limitedBy` returns non-nil index, rather than nil, but that index is invalid (out of bounds) and causes the program to blow up...

    let s = "Swift"
    
    print(s.index(s.startIndex, offsetBy: 4, limitedBy: s.endIndex))
    print(s.index(s.startIndex, offsetBy: 5, limitedBy: s.endIndex))
    print(s.index(s.startIndex, offsetBy: 6, limitedBy: s.endIndex))
outputs:

    Optional(Swift.String.Index(_rawBits: 262401))
    Optional(Swift.String.Index(_rawBits: 327681))

Re: It Can Happen to You

#113

Post by epr »

ludston wrote: post #68
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.

I think a better moral is "don't roll your own parser unless your core competency/product is the parser". Especially in a corporate situation.

Don't roll your own parser? How the hell would you get anything done? Unless you don't count regular expressions or something, I can't imagine somehow avoiding problems requiring parsers, especially on any unix-based system.

Re: It Can Happen to You

#114

Post by ALittleLight »

ineedasername wrote: post #97

Still, folks in the comments section generally agreed: they wouldn't write anything that silly. Well, if you've never accidentally crashed a system running an unexpectedly (and unnecessarily) "non-performant" piece of code then you're either an absolute genius of a coder, or relatively inexperienced.

I don't think it's a problem that they wrote anything "that silly" (okay - maybe that list/hashmap construct was pretty stupid to write originally). Instead, I think it is that they were satisfied with 6 minute load times for years. They should have been profiling this and tracking it themselves prior to launch, getting customer feedback, etc. Someone should have realized this was a problem and then developers on their team should have taken out the profilers and figured out what was up and how to make it come down.

Re: It Can Happen to You

#115

Post by fermienrico »

mkeeter wrote: post #27

Blog author here! Thanks to HN for warning me about sscanf at exactly the right time – within a day of me trying to load some ASCII STLs and noticing it was slow... Linked deep in the Twitter replies [1], there's an open glibc issue about this, dating back to 2014: https://sourceware.org/bugzilla/show_bug.cgi?id=17577 C doesn't have any requirements on the complexity of sscanf, so it might not be a bug per se, but it…

Love the post, except for the title. It is too click-baity.

Re: It Can Happen to You

#116

Post by bzbarsky »

eternalban wrote: post #92
rudedogg wrote: post #38

Earlier quoted context omitted.

Funny, the ergonomics of the Swift string API are so bad that I've started learning a lower level language for parsing, etc. Here's my favorite WTF: https://christiantietze.de/posts/2020/01/string-index-offset...

You can fault the docs but what's the problem with the API? Why should you be surprised that accessing a collection with 'nil' index is a runtime error? What else could it be? A simple fix in the doc seems to solve the confusion: "Returns an index that is the specified distance from the given index, unless that distance is beyond a given limiting index [in which case it returns nil]". It does say "returns an index ..…

If s.index() returned nil, the "if" would test false and the s[i] would not be reached.

The problem is that it returns non-nil, but the _limit_ is broken in this case: using s.endIndex as a limit means you can get non-nil but bogus indices returned. And yes, this is the fault of the docs for using a broken last arg to the API, but there's no really clean way to use this API as designed, afaict. At least not if you want to limit to "end of string" as opposed to "some index into the string that I already know to be valid".

Re: It Can Happen to You

#117

Post by 20thCB »

C string processing is the other "billion dollar mistake" we are all paying for decades later (in terms of slow programs, time wasted, power used etc).

Re: It Can Happen to You

#118

Post by lostdog »

moonchild wrote: post #56

(Originally on lobsters[0].) I maintain my original position that sscanf calculating the entire length of its input is absolutely ridiculous. Are *scanf difficult to use safely, not very robust, and somewhat baroque? Yes. Should sscanf("%f") be a correct (not performance-killing) way of reading floats? Also yes. (Though aside: the OP seems to be reading data from files, so they could have just used fscanf, which has…

Exactly. If the standard library's sorting function executed in O(n^5), I would consider that a problem with the standard library.

Re: It Can Happen to You

#119

Post by epr »

groby_b wrote: post #44
epr wrote: post #34

Earlier quoted context omitted.

Keeping track of algorithmic complexity would be nice as a language and/or static analysis feature. If you wanted to be exact or do it for a language with complex metaprogramming I assume it would be a nightmare to implement. Absent those complications and especially if you always reduced it to O(1), O(n), O(log(n)), etc it might not even be that difficult given the potential advantages.

The difficulty here is "define n". And I don't mean that facetiously. You have a string parsing lib. It is, for reasons, quadratic over the number of strings parsed, and linear per string. This is overall n^3, but that's meaningless because there actually isn't just one n. So, more m^2 * n. That means you can't reduce it to anything, because you want to keep both components. (Because, say, you know it will only ever…

I guess you're right. Keeping track of it all is required for the information to be meaningful enough. Still seems doable to me, assuming the functions are pure.

Here's another crazy idea: keeping track of this while taking into consideration aggressive compiler optimizations.

Re: It Can Happen to You

#120

Post by 0xcde4c3db »

BenFrantzDale wrote: post #77
CGamesPlay wrote: post #72

Earlier quoted context omitted.

And maybe, in a decade or so, the man page for these functions will list their algorithmic complexity! That was the most interesting takeaway from this article, for me at least. I have only seen a one or two libraries that actually list this in their documentation.

All of the C++ algorithms list complexity guarantees, I believe. This saga stunned me to learn that C doesn’t seem to do this.

It's easy to forget that the original C standards were largely codifying existing practice during an era when using gets() [1] was existing practice. The world wasn't quite ready for Ada, I guess. Best-laid plans of mice and men etc. etc..

Also, keep an eye out for "amortized" complexity. This does have a legitimately rigorous definition, but for latency-bound paths it can practically amount to "O(whatever), except for the particular invocations that are far, far worse under unspecified conditions".

[1] https://www.man7.org/linux/man-pages/man3/gets.3.html#BUGS

Post reply on HN