1. 44
  1. 7

    Imagine being like this irl

    1. 9

      This is pretty tame for a Linus rant, hah.

      1. 5

        Only one four letter word and he didn’t directly call someone an idiot? Linus is losing his edge.

        1. 1

          still embarrassing imo

          1. 2

            It might be a cultural/generational difference, but this sort of talk is standard fair (not exceptional) among many developers, especially in the low-level linux world.

            So you have to understand it in the context of its culture. Given the lack of profanity and direct insults, and the lengths he went to explaining something, this can be interpreted as a rather polite email. You just have to adjust your Bayesian priors accordingly. ;)

            1. 3

              I might be off, but that style to me feels very specifically localized to one generation, the ‘80s-'90s one, roughly Usenet culture and its mailing-list successors. Less common either earlier or later than that period.

              1. 3

                It’s still plenty embarrassing.

                1. 1

                  You might find it that way, but again, that does not mean everyone does. I didn’t find anything embarrassing about it, quite the opposite I find it curious that some consider it to be embarrassing (which is not to discount their pov either).

                  1. 2

                    if my buddy was hanging out with me and some other people we don’t know and my buddy started acting like this I’d be embarrassed. That’s what embarrassing is.

          2. 4

            FWIW he’s far more civil later on in the thread: https://lkml.org/lkml/2015/9/3/499

          3. 1

            void MyFunction(const int myData[MYDATALEN]);

            Sure, that will be turned into a pointer at compile time, but surely it is useful for self documenting what should be passed in? The compiler can even type check it so you can’t pass a shorter or longer array. Ideally it would be wrapped in a struct/class and you would pass a const MyData&, but hey, we can’t always dictate how data is used or how our function is called.
            And yes, I know I used C++ specific keywords, I’m sure you can work it out.

            1. 35

              When the documentation makes it look like something it’s not, it’s not useful. It’s the opposite.

              I was burned by exactly this bug before. And for exactly the same reason. Refactored some code using an array into a new function, but left the sizeof() as before. And it looked right, because the letters on the screen were telling me it was an array, not a pointer.

              Never. Again.

              1. 14

                If you want to document the length of the array, just document the length of the array. Don’t write code that barely compiles because “it’s self documenting.”

                1. 6

                  It really is very misleading, even if it can look “prettier”, and some people will argue that it’s “documentation” about how the pointer is a particular size. But it’s neither. It’s basically just lying about what is going on, and the only thing it documents is “I don’t know how to C”. Misleading documentation isn’t documentation, it’s a mistake.

                  1. 2

                    The compiler can even type check it so you can’t pass a shorter or longer array.

                    I don’t think the compiler can meaningfully do this as, except for sizeof and &, an array decays to a point on any operation. This makes it pretty usefull to type check unless your usage of the array is always 1 function call deep.

                    1. 1

                      I don’t think the compiler can actually use it to type check, though, because the size of the array isn’t part of the type. As far as the compiler is concerned it’s just a pointer argument with different syntax.

                      Here’s a small test case, and neither gcc or clang give a warning or error. Clang gives a warning about the sizeof() in my_function returning the sizeof(int*), though.

                      1. 1

                        I should have said “The compiler could even type check it”.
                        I meant it could enforce this behaviour:
                        int* myIntPointer = GetSomething();
                        MyFunction(myIntPointer); // Error, passed a pointer to unknown quantity of int
                        int myArray[MYDATALEN];
                        MyFunction(myArray); // Yay, length known at compile time, go ahead buddy!

                        1. 3

                          And if you want to call the function on a pointer returned from GetSomething? This seems error prone and you’ll be fighting the compilers efforts to create pointers at every turn.

                          If you want to do this, no half measures.

                          struct etheraddr {
                              Unsigned char bytes[6];

                          Pass around pointers to that and sizeof will always behave predictably, it’s type safe, even better self documenting.