11 ms·
“People who implement new and improved interfaces always seem to get that wrong”
- vfc1 11y agothis one made me think on improvement refactorings that always break something, even though the old code needed improvement. Specially just before releases.
- mreiland 11y agoThe best time to push to production is Friday afternoon, everyone knows that!
- Mtinie 11y agoAgreed! Do you wait until the Friday afternoon right before your DevOps lead is scheduled to leave for a well-deserved vacation, too? In my experience it really takes things to a whole new level of awesome!
- protomyth 11y agoHaving been the victim of a DBA pulling that stunt, my blood pressure still goes up a bit when its mentioned.
- AnimalMuppet 11y ago"I don't always test my code. But when I do, I test it in production." Credit where due: I stole that from a co-worker named Kalen Braley. (He doesn't actually do that, as far as I know.)
- deathanatos 11y agohttps://www.thinkgeek.com/product/f141/ https://www.thinkgeek.com/product/f141/ — if you want it on a shirt :-)
- AnimalMuppet 11y agoAh. So my coworker stole the saying, just like I stole it from him.
- voltagex_ 11y agoThose kind of refactorings are what really made me believe in CI and good unit tests. It doesn't pass? You don't commit it!
- vfc1 11y agoBut if the CI breaks means you already committed it, and it will get pushed to production, too late!
- lobo_tuerto 11y agoNo, that's exactly what CI services an pushing to candidate branches are for.
- gamegoblin 11y agoIf one's CI does not have a pre-production stage with integration tests, automatic blockers, and automatic rollback, one should rethink their CI design.
- softawre 11y agoGerrit is a thing (and you should run your tests locally, if you can)
- voltagex_ 11y agoSorry, I should have said "if it doesn't build, you don't merge it"
- aprdm 11y agocommit -> CI -> PASSES TESTS -> DEPLOY how is it going to be pushed to production if it fails tests ? :P
- draw_down 11y agoHow will it get pushed to production if there is no build artifact, because the build failed? This is what CI is.
- aardvark179 11y ago
- thomasahle 11y agoif (isdigit(*str)) { - io_tlb_nslabs = simple_strtoul(str, &str, 0); + str += parse_integer(str, 0, &io_tlb_nslabs); and obviously nobody spent even a *second* asking themselves "what if parse_integer returns an error". Can anybody explain why parse_integer would return an error, when isdigit(*str)? Also, why is the result (presumably integer) added back to the string? EDIT: Regarding to "adding to the string" I realize that's just C pointer arithmetic.
- username3 11y agoMaybe under some race conditions.
- ajross 11y agoNot sure because I didn't read the parse_integer patches. But the converse is a problem. isdigit("-2") returns false but the value will parse correctly.
- monochromatic 11y agoHow is that a problem though?
- interdrift 11y agoparse_integer takes a string not a char, didn't look at the implementation either but it makes sense to check for the whole string doesnt it)
- deleted 11y ago[deleted]
- gpvos 11y agoI haven't seen the code of parse_integer, but it could be on overflow, i.e., a too large number.
- victorNicollet 11y agoAn overflow may happen if there is an overflow for the type (e.g. reading '300' into an unsigned char). The function returns either a positive number indicating the number of characters successfully read from the string (if it encountered a non-digit character) or a negative number indicating an error code. https://lwn.net/Articles/643159/ https://lwn.net/Articles/643159/
- jeremysmyth 11y agoMuch as I like git, its inconsistencies wind me up sometimes. Anything that's not very commonly used or immediately obvious tends to be buried in some arcane option, and not always an option to a command you'd expect. This is not a non-sequitur: Linus might have thought good things while first implementing git, but it's one example of a tool that I use on the command line but has many, many alternative UIs that all claim to be better (not just graphical, even CLI) interfaces.
- seiji 11y agoGit isn't the best system—it just became the most popular system. http://git-man-page-generator.lokaltog.net http://git-man-page-generator.lokaltog.net
- mizzao 11y agoWow, that is hilarious. I actually didn't realize it was a joke until I tried to decipher what the command was doing and got thoroughly confused.
- d23 11y agoHere's an easier to remember one if you're interested, without the warning at the top :) http://git-scms.com/ http://git-scms.com/
- 0xdeadbeefbabe 11y agoSeems to me that it became popular because it was better than other popular options at the time like CVS and SVN. I use it today because of a choice I made in the past, and I can use it more effectively today than hg.
- seiji 11y agoGit is popular because when GitHub was in full startup mode (and not the current $350 million in cash, sit-on-their-hands mode), they ran bar meetups and gave every ruby novice in the world free alcohol to join their platform. Turns out free booze times tens of thousands of initial users beats the better interface of hg being advertised on impersonal mailing lists. At this point, (experienced) people have just gotten used to all the weird edge cases and overly complex ways of doing things with git, so changing back to a simpler way is now more complicated.
- TallGuyShort 11y ago>> People who implement new and improved interfaces always seem to get that wrong. How many lessons we seem to have to learn the hard way in our careers that others before us have learned: https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_second-system_effect https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sec...
- rqebmm 11y agoA corollary of "if it ain't broke don't fix it" is "if you can't read it don't refactor it." http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
- munificent 11y agoIt really bugs me that "refactoring" has been taken to mean any code change (hopefully) without end-user visible effect. We didn't need a new word for that. Refactoring is about doing that in a rigously reliable way. My rule is, if you don't have good tests, you aren't "refactoring" you're "moving shit around and praying you don't break something".
- jeremiep 11y agoMy rule is: tests only check the presence of bugs, not their absence. And is usually little more than wishful thinking to delude people into believing their code to be bug-free. Understanding the code is worth WAY more than having good tests. Most of the great programmers who inspire me don't write tests but have the deepest understanding of whats going on.
- npizzolato 11y agoI've seen far more problems from people who think they understand the code so they don't need tests than from people who write tests to check their code. The best of the best might be able to get by without tests, but us common-folk stand to benefit a lot from writing tests and listening to the design feedback they provide.
- jeremiep 11y agoWhile I agree with the general idea in theory, I haven't seen it happen that often in practice. More often than not tests will constrain the architecture of the actual system and result in code that is much more complex than what is required to solve the problem at hand. People then start having blind faith in their tests while being completely oblivious to what they don't test. At that point the codebase is such a mess that you do need tests to maintain it. People who focus on understanding their code work very, very hard to keep their codebase simple enough to quickly wrap their heads around it. I know I modify my codebase way too much for it to have tests - I'd spend more time refactoring the tests than progressing and I wouldn't be able to simplify the architecture as much because my attention is now on how testable the code is rather than how simple it is. I see projects shipped with unittests that still required maintenance and debugging 6 months down the road, and others without tests that worked flawlessly out the door. Of course, there's a difference between understanding and thinking you understand, but that's another matter entirely as we're walking into Dunning-Kruger territory! I'm not saying tests are bad! Far from it, I do write tests for functions where the logic isn't obvious, but my point is that there's too much focus on testing and not enough on actual quality and simplicity.
- jandrese 11y agoI'm curious what Linux has against the strl* functions. He says that they can be implemented wrong too, but it seems like they are harder to screw up than the strn* versions that required you to manually terminate the string when it hits maximum length.
- icebraining 11y agohttps://lkml.org/lkml/2015/4/28/570 https://lkml.org/lkml/2015/4/28/570
- cremno 11y ago>the strn* versions that required you to manually terminate the string when it hits maximum length This is from the description of the not-easy-to-use strncat(): >A terminating null character is always appended to the result. So your statement is only true for strncpy(). Unlike many other C functions it doesn't deal with C strings (null-terminated character arrays), but rather with fixed length and possibly null padded character arrays. People are just misusing it for some false sense of security. It may seem strange but snprintf() is the only secure string copy function defined by ISO C99.
- mzs 11y ago$ ./a.out kjv.txt Hmm... Why is this taking so long? ^\ $ db core ... a.c:28:strlcpy(dst, src, 8); ... > d src 0040000: 496e 2074 6865 2062 6567 696e 6e69 6e67 In the beginning 0040010: 2047 6f64 2063 7265 6174 6564 2074 6865 God created the 0040020: 2068 6561 7665 6e73 2061 6e64 2074 6865 heavens and the 0040030: 2065 6172 7468 2e20 4e6f 7720 7468 6520 earth. Now the ... Oh, that's why.
- jandrese 11y agoThat doesn't explain anything. The manpage explains the problem though: RETURN VALUES The strlcpy() and strlcat() functions return the total length of the string they tried to create. For strlcpy() that means the length of src. For strlcat() that means the initial length of dst plus the length of src. While this may seem somewhat confusing, it was done to make trunca- tion detection simple. So strlcpy/strlcat parse all of src regardless of what you pass on that third parameter. And they'll happily run off the end of the buffer if your string isn't null terminated. I see what Linus was so mad about now. All because they want to return the length of the original string instead of the length of the copied string. The underlying problem is that C is too limited in return types from functions. There should really be a fourth (optional) flag to strncpy that is set if the string was truncated to fit in the new buffer, and the function would return the number of characters copied, not the number of characters in the source string.
- lighthawk 11y ago“People who implement new and improved interfaces always seem to get that wrong.” Linus is completely right on this. I have seen this over and over again where developers, creative and problem solving as they are, attack things with their limited experience and knowledge and fail to understand things fully before heading in like a bull. There is a time and place for that sort of behavior, though. Linus wrote Linux with that same mentality. Sure, he was exponentially smarter and more able. :) But, that was the time for starting fresh with a cavalier attitude. However, if you try to contribute something like this to Linux today, as mature and stable as it is, and majorly screw it up, yes, you are wrong and expect your ass to get chewed. I just worry for Linux's sake who, if anyone, will be able to replace Linus if he were to choose to retire or were whisked away by aliens (I won't say die). Some related discussions about that: http://ubuntuforums.org/archive/index.php/t-424721.html http://ubuntuforums.org/archive/index.php/t-424721.html https://www.reddit.com/r/linux/comments/2fnnva/what_would_happen_to_linux_kernel_if_linus/ https://www.reddit.com/r/linux/comments/2fnnva/what_would_ha...
- therealidiot 11y agoReminds me of the CADT model http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html
- jordanlev 11y ago> attack things with their limited experience and knowledge and fail to understand things fully before heading in Over the years I gradually came to this core truth of programming: solving problems is easy, it's understanding what the problem is that's hard. Kinda sorta similar to "it's not about coding, it's about modelling": http://www.chris-granger.com/2015/01/26/coding-is-not-the-new-literacy/ http://www.chris-granger.com/2015/01/26/coding-is-not-the-ne...
- nostrademons 11y agoAlso, understanding which problems are worth solving is hard as well. That's where the "charge in like a bull" approach can be handy: a number of problems are worth solving that people shy away from, either because they're viewed as too inconsequential or because they're viewed as too difficult, and they don't get resources devoted to them until somebody has paved the way with a quick & dirty solution.
- hanlec 11y agoThis got me thinking how much test coverage exist for the kernel. It sounds like most of those issues could've been caught by tests (and I'm not referring to API compatibility, but purely to the behavior of the implementation)
- shmerl 11y ago> We had similar issues with the completely moronic and misdesigned crap called "strlcpy()", which was introduced for similar reasons, and also caused nasty bugs where the old code was actually correct, and the "converted to better and safer interfaces" code was actually buggy. What's wrong with strlcpy? When I need one, I take the code from OpenBSD: http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/string/strlcpy.c?rev=1.13&content-type=text/plain http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/... Reasons for having it are surely not moronic because it provides security benefits.
- vezzy-fnord 11y agostrlcpy(3) is actually used quite heavily throughout the Linux kernel: http://lxr.free-electrons.com/ident?i=strlcpy http://lxr.free-electrons.com/ident?i=strlcpy I'm not sure what Linus intended.
- shmerl 11y agoThough for some reason it still didn't make it into glibc.
- heinrich5991 11y agoThat's because C never has problems with buffer overflows. What's far worse: strlcpy truncates the string in case it wouldn't fit the buffer!
- mzs 11y agoUlrich Drepper was the maintainer of glibc at the time: https://www.sourceware.org/ml/libc-alpha/2000-08/msg00061.html https://www.sourceware.org/ml/libc-alpha/2000-08/msg00061.ht...
- ori_b 11y agoThe kernel developers aren't the glibc developers.
- teacup50 11y ago
- unfamiliar 11y agoString processing in C is a nightmare. It looks like you basically have to be omniscient to avoid every corner case and potential error.
- AndyKelley 11y agoString processing in computers is difficult. You have to be careful to avoid every corner case and potential error.
- progmal1 11y agoAdd multiple character sets/encodings/conversions and welcome to hell.
- ExpiredLink 11y ago> String processing in computers is difficult. Not in e.g. Java and many scripting languages.
- ori_b 11y agoWrite a function that takes three Unicode strings, concatenates the first two, and returns whether they are equivalent to the third. If your answer is "use a library", that holds for C too.
- ExpiredLink 11y agoDon't know why you are voted down, string processing is indeed unpleasantly difficult in C. Partly because a built-in string type would conflict with C's simplistic compile/link schema.
- throwaway000002 11y agoHave there been any serious attempts at an alternate string library interface for C, perhaps even an total redo of the standard C library with decades of hindsight?
- deleted 11y ago[deleted]
- slxh 11y agoMany times, it might be because most people don't like changes when what they have works, and not because the new interfaces are worst.
- rancur 11y agocan unit tests be written for every use case that's known to work with the old method, and then used on every new replacement? People wouldn't even get to submit design changes like this unless it passes all known use cases.