6 ms·

Pedantic nit: the ASCII '\0' character is called NUL, not null or NULL. C strings are NUL-terminated or zero-terminated, not null-terminated. https://en.wikipe

• taftster 7y ago
  Honest question (and not being rude). Is that strictly just being pedantic about it? Is the concept of NUL vs "NULL" semantically the same, and so you are just pointing out the ASCII abbreviation being used (three characters being consistent in the spec)? Genuinely curious if the concept of ASCII NUL '\0' can be interpreted differently in other contexts (other languages maybe)? [edit, to clarify the question] Like for example, the ASCII code '\0' is still a valid "thing" (it's a byte sequence, kind of). But in other contexts (other languages maybe), NULL is not a "thing" per se; it's more of a non-thing. How does a C programmer see the difference between NUL and NULL?
  • Sharlin 7y ago
    The two things referred to by the terms ”NUL byte” and ”null pointer” (aka ”NULL”) are quite distinct and mixing them up is not advisable, but calling the NUL byte a NULL byte, where it’s clear from the context what is meant, is not that confusing.
    • thaumasiotes 7y ago
      In the context of C, where NUL characters are most likely to be discussed, "NUL byte" and "null pointer" refer to exactly the same thing, that thing being the integer value 0.
      • AnimalMuppet 7y ago
        Only if pointers are 8 bits. More specifically, "NUL byte" is the character that has value 0, whereas "null pointer" is the pointer that has value 0. OK, I'll try to stop being the pedant. I'll let the real pedants poke holes in what I said...
        • thaumasiotes 7y ago
          > More specifically, "NUL byte" is the character that has value 0, whereas "null pointer" is the pointer that has value 0. Where is this enforced? You can assign between notional types without a problem. Whatever the context, providing 0 will have the same effect no matter how you labeled it.
          • AnimalMuppet 7y ago
            Enforced? Not, as I think you're pointing out, by prohibiting conversion. That is, if char c = '\0'; void* p = (void*)0; int a = (int)c; int b = (int)p; then a == b resolves to true. In that sense, they are the same - which I believe is your point. In that point, you are completely correct. The difference is that I can't do *c In that sense, they are not the same - not in the sense of numberic value, but in the sense of type. Also, c is 8 bits, and p (at least these days) is 32 or 64. (I pity anyone who ever had to work in an environment where p was 8 bits!) So they are the same numerically, but they are different both in type and in memory footprint.
            • thaumasiotes 7y ago
              a == p will also resolve to true. So will c == p. a and b don't add anything to your example; they're just in there to make c and p look like they're more different than they are. $ cat zero.c #include "stdio.h" int main(int argc, char* argv[]) { char nul = 0; void* null = 0; if( nul == null ) { printf("compared char to pointer; they are the same\n"); } else { printf("found a difference between char and pointer\n"); } return 0; } $ gcc -o zero zero.c zero.c: In function ‘main’: zero.c:7:10: warning: comparison between pointer and integer if( nul == null ) { ^~ $ ./zero compared char to pointer; they are the same $ You get a warning, but not an error, for making the comparison. By contrast, assigning the integer zero to a void* isn't even a warning -- it's just a natural thing to do. There isn't another way to set a pointer to NULL. There is another way to set a character to 0, the '\0' syntax, but that's not a warning either. C will think nothing of adding '!' to 'P' and getting 'q'. That's not strange because addition is a pretty normal thing to do with integers. You're right that a char variable should only occupy 8 bits of memory, but that's an implementation artifact, not a theory of what the value '\0' means. That value is unambiguously the integer zero with infinite precision. The reason it only occupies 8 bits is that you can't let it have infinite bits.
      • Sharlin 7y ago
        That’s not accurate. NUL byte is a byte with an all-zeros bit pattern, where a null pointer is a special pointer value (and thus pointer-sized) that can be coerced from the integer literal 0, but not in general from an arbitrary integer with value zero, and what’s more, a null pointer value is not guaranteed to have an all-zero bit pattern!
• jfk13 7y ago
  IMO, you're being a bit too pedantic here; it's perfectly reasonable to refer to a "null byte" or "null character". https://en.wikipedia.org/wiki/Null_character https://en.wikipedia.org/wiki/Null_character It's true that "NUL" is the usual abbreviation for this value in character code charts/standards.
  • kevin_thibedeau 7y ago
    NUL is explicitly 7 bits. Any other null could be larger than a machine byte.
  • DonHopkins 7y ago
    I am disappointed this URL does not redirect to that page: https://en.wikipedia.org/wiki/%00 https://en.wikipedia.org/wiki/%00 But what the hell does it do??? In Safari and Firefox, I get an nginx 400 Bad Request page from en.wikipedia.org. But in Chrome, it seems to be redirecting to a google search for the same url, when I type it into the address bar. Well, that's meta. Chrome won't even let me drag-and-drop that icky %00 terminated url from one page into another page to navigate there -- it angrily rejects it and sadly animates the evil url back to where it came from (though dragging it into an existing or new tab mysteriously works). But actually clicking on that link immediately goes to a blank purgatory page with the url "about:blank#blocked". Those are Chrome's stories, and it's sticking with them. At least this works: https://en.wikipedia.org/wiki/%01 https://en.wikipedia.org/wiki/%01 >Special Page >Bad title >The requested page title contains an invalid UTF-8 sequence. >Return to Main Page. Oh, yeah -- PHP: https://webmasters.stackexchange.com/questions/84008/url-encoded-query-string-with-embedded-null-00-breaks-on-some-servers https://webmasters.stackexchange.com/questions/84008/url-enc... If not the actual NUL character, then at least the Unicode Symbol for NUL redirects to the page on the Null character. https://en.wikipedia.org/wiki/␀ https://en.wikipedia.org/wiki/␀ >Null character >From Wikipedia, the free encyclopedia >(Redirected from ␀) >For other uses, see Null symbol. ...But then again, shouldn't the Null symbol ␀ redirect to the page on the Null symbol, which it actually is, not the page on the Null character, which it only symbolizes? https://en.wikipedia.org/wiki/Null_symbol https://en.wikipedia.org/wiki/Null_symbol
    • 7y ago
• raverbashing 7y ago
  Even your link tells specifically the name of '\0' is Null, NUL is merely an abbreviation See the table here https://en.wikipedia.org/wiki/ASCII#Control_characters https://en.wikipedia.org/wiki/ASCII#Control_characters
• kelnage 7y ago
  Better let Wikipedia know that then! https://en.wikipedia.org/wiki/Null-terminated_string https://en.wikipedia.org/wiki/Null-terminated_string
  • deleted 7y ago
    [deleted]
• monocasa 7y ago
  So the BEL character rings a bel on the user's terminal?
• DonHopkins 7y ago
  ACK!
• mdiesel 7y ago
  I agree, and I think it's an important distinction as sizeof('\0') is not the same as sizeof((void*)0). However, the standard does talk about null characters throughout as being a character code of value zero, as opposed to NULL the macro.
• sbmassey 7y ago
  Fine as long as you call the backspace character BS and the tab character HT.
  • earenndil 7y ago
    But then you have to call vertical tab VT, and then you have no name for a virtual teletypewriter.
• taneq 7y ago
  I used to be pedantic about this one, now I just use 'null' because that's what everyone else uses and so they'll know what I'm talking about. If I really want to be picky I'll use '\0'.