Comment by sanxiyn

Example:

  #include <stdio.h>
  #include <string.h>

  #define strlcpy(dst, src, size) ((size_t) snprintf(dst, size, "%s", src))

  size_t (strlcpy)(char *dst, const char *src, size_t size)
  {
    return strlcpy(dst, src, size);
  }

  int main(void)
  {
    char littlebuf[8];
    strlcpy(littlebuf, "Supercalifragilisticexpealidocious", sizeof littlebuf);
    return 0;
  }


  strlcpy.c: In function ‘main’:
  strlcpy.c:4:63: warning: ‘%s’ directive output truncated writing 34 bytes into a region of size 8 [-Wformat-truncation=]
   #define strlcpy(dst, src, size) ((size_t) snprintf(dst, size, "%s", src))
                                                               ^
  strlcpy.c:14:22:
     strlcpy(littlebuf, "Supercalifragilisticexpealidocious", sizeof littlebuf);
                      ~
  strlcpy.c:14:3: note: in expansion of macro ‘strlcpy’
     strlcpy(littlebuf, "Supercalifragilisticexpealidocious", sizeof littlebuf);
   ^~~~~~~
  strlcpy.c:4:34: note: ‘snprintf’ output 35 bytes into a destination of size 8
   #define strlcpy(dst, src, size) ((size_t) snprintf(dst, size, "%s", src))
                                   ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  strlcpy.c:14:3: note: in expansion of macro ‘strlcpy’
     strlcpy(littlebuf, "Supercalifragilisticexpealidocious", sizeof littlebuf);
     ^~~~~~~

If glibc doesn't do something in the header file such that we get similar diagnostics for its strlcpy, we can make the argument that this is detrimental to the program.

There is a hierarchy of bugs involved here. Memory safety is a much more serious class of problem. Obstinately refusing to improve the status quo because it doesn't solve all problems is just plain bad engineering. Doubly so in this case where there exist the "n" variants of string functions that are massive foot guns.

Pretty much all operating system APIs use C-style zero-terminated strings. So while C may be historically responsible for the problem, not using C doesn't help much if you need to talk to OS APIs.

As a user posting from a Linux machine, I disagree. Though it seems the "don't use C" crowd often delegate the important decisions to somewheres else.

I guess the answer is "some people's C is good enough, but not yours"

This thread reminds me of the essay, "Some were meant for C"

https://www.humprog.org/~stephen/research/papers/kell17some-...

C the needle contaminated now often with deadly RCE virus. Historically it was used to inject life into the first bytes of the twisted self perpetuating bootstrapping chain of an eco system dominating today the planet and the space around it.

All processors are C VMs at the end of the day. They are designed for it, and it's a great language to access raw hardware and raw hardware performance.

I still fail to label C as evil.

P.S.: Don't start with all memory management and related stuff. We have solutions for these everywhere, incl., but not limited to GCs, Rust, etc. Their existence do not invalidate C, and we don't need to abandon it. Horses for courses.

What's up with people seeing an analogy and going "you can't equate those two things"? Analogies aren't equating things

I feel like the success rate of getting someone off of null terminated strings is probably lower than most rehabilitation programs.

I mean it’s a wash, on the one hand zero terminated strings have done untold amounts of damage[0] and are impossible to extirpate once they’re in, on the other hand the nazis were methed (and coked later on) up their eyeballs.

[0] and not just in C itself, unexpected truncation through FFI is an issue which regularly pops up