> As a useful counterexample, glib has GArray, GPtrArray, and GList, along with functions that you use to manipulate the lists. Those functions are presumably i

> As a useful counterexample, glib has GArray, GPtrArray, and GList, along with functions that you use to manipulate the lists. Those functions are presumably implemented correctly, and will prevent you from making out-of-bounds accesses. > But of course those things are not widely adopted, because they're not standardized, they're not in libc, and libc has not been reimagined such that all of its APIs take and return these safer list primitives instead of bare C arrays. I'm really not sure why the second thing is regarded by C programmers as such an insuperable barrier to the first thing. I absolutely understand that there are circumstances where extreme portability is a major requirement. That, and C's ability to operate in highly constrained environments are among its most laudable features. But many of us (including me) write user-facing C applications that have neither requirement and where Glib is either already installed or easy to install. Why not just go ahead and use it? If you're trying to get it to run on a tiny embedded system or in some land without Glib . . . well, this isn't the program for you! I feel like this is more of a weird cultural prejudice than a technical matter. People run programs in JavaScript (or Haskell, or Python) with hundreds of dependencies, and while some find that annoying, I don't hear people in these communities objecting to idea of dependencies the way people do with C. Could the standard library be better? Of course. But there's something to be said for not including a lot of batteries in the standard and just using the third-party tools that are available.