Git's list of banned C functions • Hacker News Board

Re: Git's list of banned C functions

#361

Post by badsectoracula » Fri, Mar 05, 2021, 12:58 AM UTC

DaiPlusPlus wrote: post #202

lalaithion wrote: post #124

Earlier quoted context omitted.

The expectation of a C89 programmer is that a valid C89 program can be compiled for any machine that has a C89 compiler, and likewise for C95, C99, C11, and C17. Furthermore, it's expected that any C89 program can be compiled unchanged on any future version of C, and the standard library is part of the definition of the language, and therefore functions cannot be removed.

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 above it.

Re: Git's list of banned C functions

#362

Post by lmilcin » Fri, Mar 05, 2021, 1:01 AM UTC

whatisthiseven wrote: post #215

lmilcin wrote: post #67

To respond to some of the comments. It is not that there is anything intrinsically wrong with these functions. You can technically use all of them and I have been using all of them, safely, for decades. The issue is they are huge traps to the point that in a larger piece of software one can say "well, it's just not worth it". You can go much, much, much further than that. In couple embedded projects I worked some of…

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 time.

For example, allocation in Java is basically incrementing the pointer. And deallocation for most objects is basically forgetting the object exists.

No, you don't want to "limit the use of new", that's wrong approach.

What you want is to have objects that are either permanent or last very short amount of time.

The worst types of objects are ones that have kind of intermediate lifetime ie if they are allowed to mature from eden. These cost a lot to collect.

The objects that have very short lifetime are extremely cheap to collect.

So if your function takes arguments, creates couple of intermediate objects and then never returns them (for example they were just necessary for inner working of the function) and your function does not call a lot of other heavy stuff, then it is very likely the cost of those temporary objects will be very low. Also, they tend to be allocated very close to each other and so pretty well cached.

Re: Git's list of banned C functions

#363

Post by sellyme » Fri, Mar 05, 2021, 1:03 AM UTC

rbanffy wrote: post #346

jchw wrote: post #45

Earlier quoted context omitted.

Unfortunately, much of the pain with C surrounds dealing with strings. It’s been a bit of a theme on Hacker News for the past few days, but it’s actually a pretty good spotlight on something I feel is not always appreciated - strings in C are actually hard, and even the most safe standard functions like strlcpy and strlcat are still only good if truncation is a safe option in a given circumstance (it isn’t always.) (…

> strings in C are actually hard, Strings in C are more like a lie. You get a pointer to a character and the hope there is a null somewhere before you hit a memory protection wall. Or a buffer for something completely unrelated to your string. And that's with ASCII, where a character fits inside a byte. Don't even think about UTF-8 or any other variable-length character representation. In fairness, the moment you rea…

> In fairness, the moment you realize ASCII strings are a tiny subset of what a string can be, you also understand why strings are actually very complicated.

Oh absolutely, but it's a pretty reasonable expectation that any contemporary language should handle that complexity for you. The entire job of a language is to make the fundamental concepts easier to work with.

Re: Git's list of banned C functions

#364

Post by spc476 » Fri, Mar 05, 2021, 1:03 AM UTC

rrauenza wrote: post #107

_kst_ wrote: post #68

Earlier quoted context omitted.

strncpy() is not a "safer" strcpy(). It can avoid some errors involving writing past the end of the target array ( if you tell it the correct length for that array), but it's not a true string function, and it can leave the target unterminated and therefore not a valid string. http://the-flat-trantor-society.blogspot.com/2012/03/no-strn...

I never could really understand the point of strncpy()... we always end up wrapping to deal with writing an unterminated string. Was it intended for fixed length records?

Yes it was. On early Unix systems, each entry in a directory was bascially:

    struct dir
    {
      char name[14];
      int  inode;
    };

Adding a NUL byte might waste a full byte that could otherwise be used---remember, back when C was first developed, 10M disks were large and very expensive.

Re: Git's list of banned C functions

#365

Post by lmilcin » Fri, Mar 05, 2021, 1:04 AM UTC

closeparen wrote: post #181

lmilcin wrote: post #67

To respond to some of the comments. It is not that there is anything intrinsically wrong with these functions. You can technically use all of them and I have been using all of them, safely, for decades. The issue is they are huge traps to the point that in a larger piece of software one can say "well, it's just not worth it". You can go much, much, much further than that. In couple embedded projects I worked some of…

How often does the dynamic allocation rule lead to an ad-hoc allocator appearing inside the program? Also doesn’t the OS lie? I thought the memory wasn’t really physically assigned until first use.

Why would you want to implement your own allocator?

The goal of these rules is to improve reliability and timeliness of your application. If you intend on working around those rules to do what the rules explicitly forbid then either you or the rules are wrong.

Re: Git's list of banned C functions

#366

Post by mytec » Fri, Mar 05, 2021, 1:06 AM UTC

lordgroff wrote: post #216

retrac wrote: post #166

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

Oh Pascal, why couldn't we have had you instead.

"Oh Pascal" reminded me of a book titled, "Oh! Pascal!" by Doug Cooper. I used it to learn Pascal.

Re: Git's list of banned C functions

#367

Post by Someone » Fri, Mar 05, 2021, 1:07 AM UTC

selfhoster11 wrote: post #199

JoeAltmaier wrote: post #175

Earlier quoted context omitted.

Hey, languages used length,blob even when C was invented. HP Access BASIC used that kind. It was a limitation, because they chose a byte length (to save space). So strings up to 255 characters only. It was decades before folks were comfortable with 32-bit length fields. And that still limited you to 4GB strings. In the bad old days, memory usage was king.

The funny thing is that you can just use the topmost bit of the length to indicate that the string length is >127, and chain as many length bytes as you want before you begin the string proper (to save space). It would be still a better encoding than a null at the end.

Pascal compilers of the time when Pascal was popular typically had a switch that disabled range checks for speed reasons.

Such a system would effectively remove that feature. Yes, you could disable range checks when indexing into a string, but you still would have to figure out how many length bytes there are. That would only be a little bit faster than a full range check.

Because of that, I don’t see how that would have been useful at the time.

Re: Git's list of banned C functions

#368

Post by astrange » Fri, Mar 05, 2021, 1:07 AM UTC

Sohcahtoa82 wrote: post #338

young_unixer wrote: post #279

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

> I don't really get the correlation between household income and programming experience in high school. > Their parents can't afford a laptop? Holy crap, the amount of privilege shown off in just two sentences is absolutely astounding. This may come as a shock to you, but a very significant number of people don't have a couple hundred dollars to buy a low-end used laptop. 40% of Americans would struggle to come up w…

> 40% of Americans would struggle to come up with $400 for an emergency expense [0], let alone save $400 for a laptop.

It actually doesn't say that, it says they don't have $400 in cash equivalents but may be able to produce it by selling "assets". So a person who keeps all their savings in CDs or investments also counts, although only for expenses you can't put on credit cards.

Re: Git's list of banned C functions

#369

Post by lmilcin » Fri, Mar 05, 2021, 1:11 AM UTC

xxpor wrote: post #313

closeparen wrote: post #181

Earlier quoted context omitted.

How often does the dynamic allocation rule lead to an ad-hoc allocator appearing inside the program? Also doesn’t the OS lie? I thought the memory wasn’t really physically assigned until first use.

It's an embedded system, it's very likely there's no OS in the first place.

Actually it is irrelevant whether you use an operating system or not.

One project I worked with these rules was on Verix OS.

The rules are more intended on reducing application complexity and unpredictability which is typically helping reliability regardless of the setting.

Re: Git's list of banned C functions

#370

Post by konjin » Fri, Mar 05, 2021, 1:11 AM UTC

michaf wrote: post #247

selfhoster11 wrote: post #199

Earlier quoted context omitted.

The funny thing is that you can just use the topmost bit of the length to indicate that the string length is >127, and chain as many length bytes as you want before you begin the string proper (to save space). It would be still a better encoding than a null at the end.

This way you would trade in a null-byte-terminated variable length string for essentially a null-bit-terminated variable length number (plus the remaining string). I am not convinced that this actually would be much safer.

In a toy language I once wrote I got around that by encoding binary values as quaternary values and using a ternary system on top of that with a termination character: 11 = 1; 01 = 0; 00 = end; 10 was unused.

Having truly unbounded integers was rather fun. Of course performance was abysmal.