Re:Git's list of banned C functions
by munchbunny on Thursday March 04, 2021 @10:36PM
(#26352284)
Thanks for the reference!
I personally don't think that the qualitative pros/cons of the chosen approach or alternatives that we're discussing today, 30-ish years later, would be all that new to the designers of C in 1993. The difference is that we've had 30-ish years to watch those decisions play out over millions of lines of code in software running at scales and levels of complexity that programmers in 1993 could only dream of.
Also, software security was barely an issue in 1993. Today, it's a massive issue.
Re:Git's list of banned C functions
by throw0101a on Friday March 05, 2021 @11:02AM
(#26358303)
> Also, software security was barely an issue in 1993. Today, it's a massive issue.
That was him reflecting on things in 1993, but the C team designed things in ~1970. That was basically the Stone or Iron Age of computing.
Thank you (and the others) in this thread. Very insightful, particularly with what motivated the thinking then.
Re:Git's list of banned C functions
by CodeArtisan on Thursday March 04, 2021 @11:04PM
(#26352539)
We could say that a string in C is an implicit type like a list in Lisp.
> None of BCPL, B, or C supports character data strongly in the language; each treats strings much like vectors of integers and supplements general rules by a few conventions. In both BCPL and B a string literal denotes the address of a static area initialized with the characters of the string, packed into cells. In BCPL, the first packed byte contains the number of characters in the string; in B, there is no count and strings are terminated by a special character, which B spelled `*e'. This change was made partially to avoid the limitation on the length of a string caused by holding the count in an 8- or 9-bit slot, and partly because maintaining the count seemed, in our experience, less convenient than using a terminator.
[…]
> C treats strings as arrays of characters conventionally terminated by a marker. Aside from one special rule about initialization by string literals, the semantics of strings are fully subsumed by more general rules governing all arrays, and as a result the language is simpler to describe and to translate than one incorporating the string as a unique data type. Some costs accrue from its approach: certain string operations are more expensive than in other designs because application code or a library routine must occasionally search for the end of a string, because few built-in operations are available, and because the burden of storage management for strings falls more heavily on the user. Nevertheless, C's approach to strings works well.
* https://www.bell-labs.com/usr/dmr/www/chist.html
He mentions Algol 68 and Pascal [Jensen 74].