Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git's list of banned C functions

github.com

Post reply on HN
Print view View original

501–510 of 639 posts

Re: Git's list of banned C functions

#501

Post by ajuc »

mjcohen wrote: post #444
WalterBright wrote: post #435

Earlier quoted context omitted.

Whenever I review C code, I first look at the string function uses. Almost always I'll find a bug. It's usually an off by one error dealing with the terminating 0. It's also always a tangled bit of code, and slow due to repeatedly running strlen. But strings in BASIC are so simple. They just work. I decided when designing D that it wouldn't be good unless string handling was as easy as in BASIC.

IIRC, in the early days of the Commodore PET, it used a method of keeping track of strings that was fine in an 8k machine but was too slow in a 32k machine. They had to make a change that avoided quadratic time on the larger machine. So string handling in BASIC wasn't always that simple.

It always blows my mind when I remember 8-bit computers had garbage-collected strings.

Re: Git's list of banned C functions

#502

Post by lelanthran »

Animats wrote: post #177
Camillo wrote: post #130

Earlier quoted context omitted.

Many of the problems with C descend from a common root, the decision to use bare pointers (memory addresses) as the basic way to refer to strings, arrays etc. If they had used a {pointer, size} pair instead, it would have avoided all of these string problems, most buffer overflows, even the GTA Online loading problem that was on HN recently.

Pascal, which had sized strings, was in wide use before C. Many people, including Bill Atkinson, who wrote many of the original Macintosh applications, thought C was a step backwards. Pascal, to save one byte, limited strings to length 255. Bad decision.

> Pascal, which had sized strings, was in wide use before C. Many people, including Bill Atkinson, who wrote many of the original Macintosh applications, thought C was a step backwards.

Sure, but parent wasn't saying "it was not possible", they said "It was too expensive".

And sure enough, the market drifted to the cheaper solution: you could run slightly more applications if your OS and applications were all written in C than if they were written in Pascal, Modula, etc.

Re: Git's list of banned C functions

#503

Post by KptMarchewa »

th3sly wrote: post #491
mjcohen wrote: post #447

Earlier quoted context omitted.

Medicine also requires, after college, medical school and a residency - typically 6 to 9 years work. Programming requires none of this.

> Programming requires none of this. But it requires you to refresh your knowledge constantly so from this point of view it's similar

If you're arguing that medicine does not, then I hope you're doing software engineering.

Re: Git's list of banned C functions

#504

Post by kaba0 »

de6u99er wrote: post #441
InvOfSmallC wrote: post #103

Earlier quoted context omitted.

I teach at university as external lecturer. Teaching strings in C is the hardest thing I have to do every time. The university decided to explain C to first year student without previous experience. My feedback was to do a precourse in Python to let them relax a bit with programming as a concept and then teach C in a second course.

I am seeing Python becoming the go-to language for many academics because it's easy to hack something together that somehow works. Unfortunately most of those developers don't care much about efficiency and Python is out of the box inefficient compared to other high-level languages like Java [1] or C#. OO Java courses circulating in academia lack modern functional, and to be frank educational, concepts and must to be…

I generally agree with you (especially on the update java guides), though I think it is important to teach C/C++ after some experience with a higher level language, if for nothing else, the large amount of already existing code bases.

I also like the newfound interest in some FP languages, I for example had a mandatory Haskell course in first year — we did not take Monads in this course yet, but I think it is a great introduction for students for a different take from the more imperative world.

Re: Git's list of banned C functions

#505

Post by scoutt »

coliveira wrote: post #232
munchbunny wrote: post #143

Earlier 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…

Null terminated strings are remnants of an era when computers had little memory available. So, at the time it seemed smart to discard the length field and use a single byte-sized terminator (null). If you are writing an operating system for a machine with little memory to spare, this seems like a good decision. Of course things are very different now when memory is not a problem and the goal is safety.

> memory is not a problem and the goal is safety.

People keep repeating this. What about embedded systems? For instance, I have to know how an object is structured and how is allocated, exactly and without surprises. The behavior has to be predictable and as simple and fast as possible. You can (likely) achieve that with C.

Re: Git's list of banned C functions

#506

Post by kaba0 »

cblconfederate wrote: post #308
InvOfSmallC wrote: post #103

Earlier quoted context omitted.

I teach at university as external lecturer. Teaching strings in C is the hardest thing I have to do every time. The university decided to explain C to first year student without previous experience. My feedback was to do a precourse in Python to let them relax a bit with programming as a concept and then teach C in a second course.

thats probably because pointers are considered "hard" , too hard to exist in other languages. It's interesting that in the 80s, the standard library modeled C++ iterators with pointer semantics because they assumed everyone could do pointer arithmetic, but nowadays the concept is not mainstream at all.

I don’t think the reason for hiding pointers is because they are hard — it’s just that arbitrary pointer arithmetics are especially error prone and can be avoided in most codebases.

Re: Git's list of banned C functions

#507

Post by scoutt »

unbalancedevh wrote: post #249
frob wrote: post #138

Earlier quoted context omitted.

As someone who learned C as their first language, strings in every single language after that have felt like cheating. "What? You mean I can type an arbitrary string and it works? I don't need to worry about terminators or the amount of memory I've allocated? You can concatenate two strings with +?!? What is this magic?"

It always makes me wonder if there's some hidden overhead that I'm absorbing. When I program in C I feel like I know a lot better what the generated instructions will be. Using higher-level languages for embedded programming where resources are tight makes me uncomfortable.

Together with parent comment, this is exactly how I feel every time I use something that is not C (I do mostly embedded). Like: ok, I can use a slice here, but what is a slice? what thing is it doing that I don't know? where's the catch? how does it look like in memory? is it calling a function when I access it? is it being copied or referenced?. And so on...

Re: Git's list of banned C functions

#508

Post by scns »

lmilcin wrote: post #362
whatisthiseven wrote: post #215

Earlier 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…

Well that seems to align pretty well with Entities/Aggregates and ValueObjects in DDD.

Re: Git's list of banned C functions

#509

Post by kaba0 »

kelnos wrote: post #410
mxcrossb wrote: post #269

Earlier quoted context omitted.

What I don’t understand is why C programmers use the built in strings. It’s like rolling your own sorting algorithm every time you need it. Surely someone could write a better string library in C that hides the complexity. The real problem is that C programmers are apparently allergic to using other people’s code.

Because most projects involve interfacing with other third-party libraries that will undoubtedly not know about this other third-party library that implements a nice string.

It can contain a to_cstring() function and problem solved.

If it uses a struct with length of string and pointer to a c-style string, even the conversion can be elided (at the price of some inflexibility/unnecessary copying while in use)

Re: Git's list of banned C functions

#510

Post by surajrmal »

lmilcin wrote: post #416
xxpor wrote: post #398

Earlier quoted context omitted.

You're redefining overcommit from how everyone else uses it. https://www.kernel.org/doc/Documentation/vm/overcommit-accou...

If you want to "allocate" (reserve) physical memory just call malloc and then mlock. No lie. You get physical pages or error. Get over it. What you call "allocation" is two distinct operations on Linux, one of which is called malloc in standard c library, unfortunately, and that's where your confusion comes from.

Overcommitting means providing more virtual memory to be mapped than is available in physical memory. It works by mapping memory as readonly, mapped to a zero page, and "committing" a real physical page when a write occurs to a page for the first time. The act of asking for virtual memory and mapping it is considered allocation. Linux overcommits virtual memory. Some OS, like Windows, actually commit physical pages to back virtual memory when you ask try to map new virtual memory.

I think you know these things and it's mostly just a semantics argument, but this is the widely agreed definition.

Post reply on HN