5 ms·

I am extremely familiar with C. I used to work on a static analyser for it. The issue is that there is very little to like in how C is designed from a PL point

I am extremely familiar with C. I used to work on a static analyser for it. The issue is that there is very little to like in how C is designed from a PL point of view. You are confusing what the language can do and what is semantic is. C strings are just a contiguous allocation of byte and a bunch of functions which interprets it as ascii characters and stop on a specific value. That’s literally the worst representation of a string you can have.

kazinator 4y ago
I think it's a nice representation, allowing easy recursion. const char *my_strchr(const char *str, int ch) { if (*str == 0) return NULL; if (*str == ch) return str; return my_strchr(str + 1); } It's a good format for storage and communication. Name any other string data structure and I will cite you all the disadvantages compared to the C string. - If the format contains pointers, you have to marshal it to a flat representation to communicate or store it. The C string is already marshaled. - If the format contains size fields, their own size matters: are they 16, 32, 64. What byte order? Again, needs marshaling. You might think not if going between two processes on the same machine. But, oops, one is 32 bit the other 64 ... I shudder to think of what FFIs would look like, if C strings were something else. It's the one easy thing in foreign interfacing. C programs themselves sometimes come up with alternative string representations, for good reasons; but those representations don't interoperate with anything outside of those programs, or groups of closely related programs.
- WastingMyTime89 4y ago
  C null terminated strings are not magic. Protocols between the sender and receiver have to be defined. You face exactly the same problem regarding byte order, size consideration and marshalling with C strings. You are basically arguing that C strings are a good default because they are the default. If they were something else, well, we would have saner FFI in a lot of place. C strings are a terrible default. They are fundamentally unsafe. Mishandle the null char for any reason and you now face a serious security issue.
  - kazinator 4y ago
    > You face exactly the same problem regarding byte order, size consideration and marshalling with C strings. Not char/byte C strings. You might be thinking of wchar_t strings. > Mishandle the null char for any reason and you now face a serious security issue. With what string data structure can applications peak into and mishandle an implementation detail and not risk creating a security problem? Same you have a structure with the length and a pointer. Mishandle the length field or pointer and you have a problem. It certainly is a problem and it's common for C applications to take on responsibilities for manipulating the internals of the string structure.
    - WastingMyTime89 4y ago
      > Not char/byte C strings. You might be thinking of wchar_t strings. No I’m talking about the classic byte arrays C pretends are strings. If the receiver you are talking to is not expecting a chain of bytes where each byte is a character and one special value means the chain is over, well, you will have to transform what you are sending to what your receiver is expecting.
      - kazinator 4y ago
        If somebody's expecting something other than a C string then we unsurprisingly have gratuitous complications. If everyone agrees on the C string though, it just interoperates as-is. Code compiled for some 16-bit microcontroller can just shove the C string into its transmit buffer, and on the other end, code compiled for 64 bit big-endian Power PC receiver just uses it as-is.
        timbit42 4y ago
        C is the biggest mistake in the software industry since the beginning of software. The people that worship C only do so because they haven't seen the better paths the software industry could have chosen.
        4y ago
- andsoitis 4y ago
  This routine only works with ASCII, yea?
  - kazinator 4y ago
    It will also find ASCII characters in UTF-8. That's a common situation because delimiting characters are often in the ASCII range. We can make a more complicated example that nevertheless uses recursion and essentially the same way, which looks for a UTF-8 character. We can examine and decode a prefix of the string as a UTF-8. If there are bad bytes or the character doesn't match then we recurse. We can also write a wide character (wchar_t) version of the function which looks the same. That will handle all of Unicode on sane platforms, and the basic multilingual plane (BMP) on Windows.
kazinator 4y ago
If that static analyzer was itself written in C, you have one program's worth of C experience, which is very little.

kazinator 4y ago

I think it's a nice representation, allowing easy recursion. const char *my_strchr(const char *str, int ch) { if (*str == 0) return NULL; if (*str == ch) return str; return my_strchr(str + 1); } It's a good format for storage and communication. Name any other string data structure and I will cite you all the disadvantages compared to the C string. - If the format contains pointers, you have to marshal it to a flat representation to communicate or store it. The C string is already marshaled. - If the format contains size fields, their own size matters: are they 16, 32, 64. What byte order? Again, needs marshaling. You might think not if going between two processes on the same machine. But, oops, one is 32 bit the other 64 ... I shudder to think of what FFIs would look like, if C strings were something else. It's the one easy thing in foreign interfacing. C programs themselves sometimes come up with alternative string representations, for good reasons; but those representations don't interoperate with anything outside of those programs, or groups of closely related programs.

WastingMyTime89 4y ago
C null terminated strings are not magic. Protocols between the sender and receiver have to be defined. You face exactly the same problem regarding byte order, size consideration and marshalling with C strings. You are basically arguing that C strings are a good default because they are the default. If they were something else, well, we would have saner FFI in a lot of place. C strings are a terrible default. They are fundamentally unsafe. Mishandle the null char for any reason and you now face a serious security issue.
- kazinator 4y ago
  > You face exactly the same problem regarding byte order, size consideration and marshalling with C strings. Not char/byte C strings. You might be thinking of wchar_t strings. > Mishandle the null char for any reason and you now face a serious security issue. With what string data structure can applications peak into and mishandle an implementation detail and not risk creating a security problem? Same you have a structure with the length and a pointer. Mishandle the length field or pointer and you have a problem. It certainly is a problem and it's common for C applications to take on responsibilities for manipulating the internals of the string structure.
  - WastingMyTime89 4y ago
    > Not char/byte C strings. You might be thinking of wchar_t strings. No I’m talking about the classic byte arrays C pretends are strings. If the receiver you are talking to is not expecting a chain of bytes where each byte is a character and one special value means the chain is over, well, you will have to transform what you are sending to what your receiver is expecting.
    - kazinator 4y ago
      If somebody's expecting something other than a C string then we unsurprisingly have gratuitous complications. If everyone agrees on the C string though, it just interoperates as-is. Code compiled for some 16-bit microcontroller can just shove the C string into its transmit buffer, and on the other end, code compiled for 64 bit big-endian Power PC receiver just uses it as-is.
      - timbit42 4y ago
        C is the biggest mistake in the software industry since the beginning of software. The people that worship C only do so because they haven't seen the better paths the software industry could have chosen.
        4y ago
andsoitis 4y ago
This routine only works with ASCII, yea?
- kazinator 4y ago
  It will also find ASCII characters in UTF-8. That's a common situation because delimiting characters are often in the ASCII range. We can make a more complicated example that nevertheless uses recursion and essentially the same way, which looks for a UTF-8 character. We can examine and decode a prefix of the string as a UTF-8. If there are bad bytes or the character doesn't match then we recurse. We can also write a wide character (wchar_t) version of the function which looks the same. That will handle all of Unicode on sane platforms, and the basic multilingual plane (BMP) on Windows.

kazinator 4y ago

If that static analyzer was itself written in C, you have one program's worth of C experience, which is very little.