1. 35
  1.  

  2. 6

    A direct link to why Arrays are not pointers:

    http://www.c-faq.com/aryptr/aryptr2.html

    1. 6

      They also have different behavior with respect to sizeof. On a 64-bit machine, if you compile and run this bit of C code:

      
      int main () {
        char string1[17] = "Omar coming, yo.";
        char *string2 = "In-dig-NAY-shun!";
        printf("%lu %lu\n", sizeof(string1), sizeof(string2));
        return 0;
      }
      

      you get an output of "17 8". The first sizeof call returns 17, the size of the array in bytes. The second returns 8, because that’s the size of a machine word/pointer (for the char *).

    2. 3

      I think its important to read pedantic articles like “How to C” with a wider context. Try reading some other thoughts from the original article’s author:

      https://matt.sh/searching-2013 – “So, the only place willing to hire me is the place where I both a.) didn’t do any live coding interviews and b.) never met anybody in person — their entire interview process was IM/Skype-based10. I’m not sure what that says about me, but I try not to think about it.”

      https://matt.sh/programming-errors – “This article is a quick overview of both technical and interpersonal errors we encounter when trying to develop software with more than one person. No literature was consulted. All thoughts are my own delusions.”

      This post is a thoughtful critique, which is more than the original article deserved. “How to C”’s author is a classic programming troll. Granted, he’s a pretty good one, which makes it hard not to respond, but he’s a troll just the same.

      Stop feeding the troll.

      1. 2

        I don’t think “troll” is a good word to describe Matt. I might call his piece an “accidental troll” instead.

        Those quotes show that Matt might not have done lots of research to back up his original article, but they don’t at all imply that Matt published the article hoping to get a rise out of people for the parts that were wrong. The article looks like a genuinely-offered, but under-researched, set of suggestions.

        1. 1

          The article opens with “The first rule of C is don’t write C if you can avoid it.” It is filled with “modern rules” and “your’re doing it wrong”, and ends with, “Writing correct code at scale is essentially impossible.”

          That piece is an accidental troll? I sense natural talent!

          1. 1

            For some reason that opening sentence is attributed to me. I’m fine with that though :D

      2. 1

        I’ve gotta say, if there’s one thing the article made me agree with, it’s the original quote:

        The first rule of C is don’t write C if you can avoid it.

        This stuff looks tricky! :)

        1. -1

          Eh. This guy is just a standards wanker who doesn’t actually offer anything of value. Yes technically a byte is not always 8 bits. But the original title was “How to C in 2016” not “How to C in the Dark Ages.” The only thing I felt was actually worth saying was the bit about ptrdiff_t / intptr_t.

          1. 6

            Can we be critical without resorting to unnecessary ad hominem attacks? While the article is certainly towards the more pedantic side, I think it’s important to truly understand what’s going on in any language I work in.

            1. 1

              I agree that it’s good to understand a language. But as a critique of the original post, I don’t find this post all that useful. The original provided a decent practical basis for modern C programming. It has it’s problems, and the author responded to those problems as they were brought up, including the legitimate criticisms from this critique. But for a critique that states it “is intended to be constructive criticism,” it sure contains a lot of stuff that doesn’t matter at all.

              And I stand by my claim of standards wankery, because he writes stuff like this:

              By emphasizing “modern” systems, you ignore both old systems (like the old x86 systems that exposed segmented addressing with “near” and “far” pointers) and possible future systems that might be perfectly compatible with the C standard while violating “modern” assumptions.

              The old systems are so old that a modern programmer shouldn’t try for code compatibility with them—at all—unless they have a particular reason to. It’s a waste of time.

              And while the possible future systems case is interesting to speculate about, they are so far off that planning for them in this way is an even bigger waste of time. Right now size_t equals pointer size which is 32 or 64 bits. No mainstream hardware manufacturer is going to get around the 32 bit address space with segmentation. For 64 bits we won’t need anything like segmented memory again until our address spaces grow larger than 16,777,216 terabytes.

              I’ll admit that I don’t have much patience for standards wankery, maybe because I’ve read a lot of it already, but I would have liked the critique a lot more if he hadn’t spend any time reminding all of us that float technically could be 64 bits.

            2. 1

              There are current day architectures where char isn’t 8 bits. For instance the SHARC DSP which has 32 bit chars.