The similar list from ClickHouse repository: https://github.com/ClickHouse/ClickHouse/blob/master/base/ha...
Git's list of banned C functions
421–430 of 639 posts
Re: Git's list of banned C functions
#422Earlier quoted context omitted.
I don't really get the correlation between household income and programming experience in high school. Their parents can't afford a laptop? They can't afford an Internet connection? The kids don't have a good place to learn in their house? They don't have time? Is programming affected more than other subjects like math, English/grammar, science, etc?
"Is programming affected more than other subjects like math, English/grammar, science, etc?" Probably a bit more, as it is common to learn other subjects by a book, but learning programming without a computer ... sounds hard.
Dijkstra probably would disagree, but his isn't a common opinion.
Re: Git's list of banned C functions
#423Earlier quoted context omitted.
If I had to choose a language to teach programmers to absolute beginners, I think I'd actually go with Go. I understand the predilection for Python but there are some parts of Python that are just... odd.
Python is great fun, and you can be really productive with it, but for people first coming into programming, a language with an explicit and strict type system is invaluable. I used to think that everyone should be taught python first, because it lets you focus on the meat of computer science - algorithms, data manipulation, actually _doing_ something - but after helping my girlfriend out with some comp sci 101-104 p…
> You can work yourself into some weird corners because of how permissive the language is, where in a (strongly) typed language, the complier just says no.
Could you share an example?
Re: Git's list of banned C functions
#424Earlier quoted context omitted.
Mainframes very quickly were outclassed by minicomputers. They could not respond quickly to technology changes as fast. C was indeed king for decades.
C was not without competition on microcomputers, either. A lot of DOS software was written in Pascal, for example - and it wasn't any slower for that.
A lot of it was written in Turbo Pascal, which (among many other things that would have caused Niklaus Wirth to break out in hives) let you include inline machine code (and later, inline assembly language).
Re: Git's list of banned C functions
#425Earlier quoted context omitted.
I think you mean GLib as seen here https://developer.gnome.org/glib/stable/glib-Strings.html GLib and GTK are closely aligned parts of GNOME so they are easy to get mixed up.
Right. The string library is in glib. There were a few big libraries in the ecosystem if I remember well, GTK, glib and another two. They're from the same origin and often mixed together. It's been almost a decade since I dabbled into this stuff day-to-day. I think being forced to use glib is the turning point in a developer's life where you realize you simply have to move on to a more usable language.
So true
Re: Git's list of banned C functions
#426Earlier quoted context omitted.
For reasons that were never clearly articulated, the prefix approach was considered odd, backwards, and to have numerous downsides, at least where I learned C. In hindsight, I can only cringe at that attitude. Strings as added in later Pascal, about 40 years ago now, were memory safe in a way that C strings still are not.
Pascal strings are not inherently memory safe: cat_pascal_strings(pascalstr *uninited_memory, pascalstr *left, pascalstr *right); how big is uninited_memory? Can left and right fit into it? You need to design language constructs around Pascal srings to make them actually safe. Such as, oh, make it impossible to have an uninitialized such object. The object has o know both its allocation size and the actual size of th…
> Working with strings in Pascal is relatively safe, but painfully limiting. It's a dead end. You can't build anything on top of it. Can you imagine trying to make a run-time for a high level language in Pascal? You need to be in the driver's seat regarding how strings work.
I doubt string representation is really the blocker here since C-strings are now pretty much just used by some but not all C programmers. QString and GString and C++ std::string and Rust strings and Go strings and Java strings and so on are not null terminated
Re: Git's list of banned C functions
#427Earlier quoted context omitted.
At a certain point we have to say that it’s wrong for someone to expect C89 should still be the LCD. And yes: it should all still compile, but none of that prohibits the compiler from issuing flashing red/yellow warning messages to your terminal for using footgun functions, preferably with uncomfortable audible notifications too. All of this is silly though, because even in a strict C89 environment you can still have…
> And yes: it should all still compile, but none of that prohibits the compiler from issuing flashing red/yellow warning messages to your terminal for using footgun functions, preferably with uncomfortable audible notifications too. As long as it is done like in recent versions of Visual C++ where i can disable that useless compiler output pollution with a #define, usually with a snide remark about Visual C++ right a…
> disable that useless compiler output pollutio
The compiler is trying to help you write better code - suppressing warnings should not be taken lightly.
Re: Git's list of banned C functions
#428Earlier quoted context omitted.
The decision to make C strings null terminated with implied length instead of length + blob continues to trip us up, 30+ years later. There's a good reason the "safe" versions of those functions all take length parameters. But way back when this approach was chosen, I don't think the state of the art could fully predict this outcome. But also, "strings" and "time" are actually very complex concepts, and these functio…
For reasons that were never clearly articulated, the prefix approach was considered odd, backwards, and to have numerous downsides, at least where I learned C. In hindsight, I can only cringe at that attitude. Strings as added in later Pascal, about 40 years ago now, were memory safe in a way that C strings still are not.
(Many of) The trade-offs were known to Richie et al; writing in 1993:
> 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].
Re: Git's list of banned C functions
#429Earlier quoted context omitted.
My experience with C courses with this structure of automatically validated home works not only filter "the weak" but also people with previous (especially C on Unix) experience, because nobody with any kind of practical Unix experience will write code that will pass these kinds of rigorous C-standard conformance and memory leaks checks, because for practical applications doing all that is actually not only unnecessa…
I think a passing test suite, no diff after clang-format, clean valgrind and clang-analyze checks are not too much to ask for. As long as the requirements are documented and the system is transparent and allows resubmission. But I agree there is a risk of academic instructors going way overboard in practice, e.g. by flagging actually useful minor standard conformance violations (like zero length arrays or properly #i…
My aversion to such systems is primarily motivated by the fact that every one of such system somehow penalized resubmissions. I probably don't have anything against "you have to write program that is compiled by this gcc/llvm commandline without producing any diagnostics and then passes this intentionally partially documented test suite". But in most cases the first part ends up meaning something like "cc -Werror -std=c89 -ansi -strict" where the real definition of what that really means depends on what exactly the "cc" is and the teachers usually don't document that and don't even see why that is required (ie. you can probably produce some set of edge-case inputs to gcc to prove that gcc is or isn't valid implementation of some definition of C, but this conjecture does not work the other way around).
Re: Git's list of banned C functions
#430Earlier quoted context omitted.
It is interesting to read the rules you came up with to limit memory usage, and then to think of the criticisms one gets in Java for limiting memory usage. In Java we try to limit new as much as possible to prevent the GC from pausing too much, or inconveniently, or for too long. And basically all the rules you say are what we also use in Java. Except when you have these rules in Java, the ironic counter-point is "if…
Having almost 20 years of experience with Java... but are not following recent garbage collector developments. There is a bunch of misconceptions about Java. Java is actually very performant and memory allocation is generally cheaper than in C (except for inability to have good use of stack in Java). What's slow about Java is all the shit that has been implemented on top of it, but that's another story for another ti…
This was very insightful. Thank you.