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

391–400 of 639 posts

Re: Git's list of banned C functions

#391

Post by loeg »

masklinn wrote: post #69
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.) (…

> Technically C11 has strcpy_s and strcat_s "Theoretically" is the word you're looking for: they're part of the optional Annex K so technically you can't rely on them being available in a portable program. And they're basically not implemented by anyone but microsoft (which created them and lobbied for their inclusion).

Microsoft doesn't actually implement Annex K! Annex K is based on MSFT's routines, but they diverged. So Annex K is portable nowhere, in addition to having largely awful APIs.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm#:~...

> Microsoft Visual Studio implements an early version of the APIs. However, the implementation is incomplete and conforms neither to C11 nor to the original TR 24731-1. For example, it doesn't provide the set_constraint_handler_s function but instead defines a _invalid_parameter_handler _set_invalid_parameter_handler(_invalid_parameter_handler) function with similar behavior but a slightly different and incompatible signature. It also doesn't define the abort_handler_s and ignore_handler_s functions, the memset_s function (which isn't part of the TR), or the RSIZE_MAX macro.The Microsoft implementation also doesn't treat overlapping source and destination sequences as runtime-constraint violations and instead has undefined behavior in such cases.

> As a result of the numerous deviations from the specification the Microsoft implementation cannot be considered conforming or portable.

Re: Git's list of banned C functions

#392

Post by kortex »

kevin_thibedeau wrote: post #373
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.

On platforms with limited register sets, keeping length around burns a register that could be used for something else. From the mindset of assembler programmers wanting a high level language that suits them, a sentinel that doesn't consume extra machine resources was preferable. Not to mention all the precious RAM those multi-byte lengths squander.

Ok, I hadn't considered the registers thing. That almost makes sense. Almost. But variable length arrays are so useful I think it warrants adding a register just for dealing with fat pointers.

Like I get why it happened. It is just crazy how long it has stuck around.

Re: Git's list of banned C functions

#393

Post by tdeck »

m463 wrote: post #345
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…

I think 30-40 years ago it was perfectly appropriate to null-terminate strings. Every byte actually counted. I remember thinking about setting the high bit to denote the end of string to save space. Nowadays the binary for "hello world" might be as big as a whole operating system of the past. (though honestly I can't recall the size of the OS on a boot floppy, but the original floppies were 160k)

Just a surreal reminder that 30 years ago was 1991. By that time it already didn't make sense to null terminate strings (except perhaps on embedded platforms).

Re: Git's list of banned C functions

#394

Post by lmilcin »

xxpor wrote: post #379
lmilcin wrote: post #369

Earlier quoted context omitted.

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.

It was mostly on if the OS would actually allocate physical memory, or if it'd do a linux style overcommit. Without an OS, the latter is very unlikely.

Again, Linux DOES NOT overcommit memory.

Linux does not lie about what available memory is. Rather, it is most developers that do not understand how memory is managed on Linux.

What you probably mean is that you don't get physical memory when you run malloc().

That's because when you allocate memory on Linux you allocate virtual address space rather than physical memory.

Basically, you get a bunch of addresses that may or may not be backed up by physical pages.

If you want physical memory you just need to use mlock() along with malloc() and you are all fine.

Re: Git's list of banned C functions

#395

Post by lenkite »

jchw wrote: post #45
paultopia wrote: post #17

Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.

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.) (…

If only C had followed the Pascal way to have the size with a string - so much human suffering could have been avoided!

Re: Git's list of banned C functions

#396

Post by throwaway3neu94 »

dfox wrote: post #349
ababaiem wrote: post #290

Earlier quoted context omitted.

Having gone through the same experience, I can tell you that it isn't necessarily the case. More often than not, those who had some programming experience in some high-level language would often get discouraged with the difficulty and drop out. In the end, it was mostly those that didn't get discouraged and socialized with the other students that would remain in the end. I myself did not have any programming experien…

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 #ifdef'd code assuming bitfield order).

Re: Git's list of banned C functions

#397

Post by ufo »

moonchild wrote: post #273
kiwidrew wrote: post #265

Earlier quoted context omitted.

I would argue that C's fundamental mistake (well, more like limitation due to hardware of the time) was allowing arrays to decay to pointers; arrays hold valuable type information (the length!) that is lost once converted to a pointer. C99 came so very very close with VLAs. You can declare a function like: int main(int argc, char *argv[argc]) { ... } But C99 requires the compiler to discard the type annotations and t…

It's because to get that to actually work you need dependent types. Which—it's not gonna happen.

We wouldn't need to go all the way to dependent types, which would guarantee at compile-time that array accesses are safe. Even if all the bounds checking happened at run-time it would still be tremendously helpful.

Re: Git's list of banned C functions

#398

Post by xxpor »

lmilcin wrote: post #394
xxpor wrote: post #379

Earlier quoted context omitted.

It was mostly on if the OS would actually allocate physical memory, or if it'd do a linux style overcommit. Without an OS, the latter is very unlikely.

Again, Linux DOES NOT overcommit memory. Linux does not lie about what available memory is. Rather, it is most developers that do not understand how memory is managed on Linux. What you probably mean is that you don't get physical memory when you run malloc(). That's because when you allocate memory on Linux you allocate virtual address space rather than physical memory. Basically, you get a bunch of addresses that m…

You're redefining overcommit from how everyone else uses it.

https://www.kernel.org/doc/Documentation/vm/overcommit-accou...

Re: Git's list of banned C functions

#399

Post by loeg »

syncsynchalt wrote: post #244
attractivechaos wrote: post #16

I wonder how they copy strings with strcpy and strncpy both banned. strlcpy? But it is not conforming to major standards. Or just memcpy with extra code?

strncpy is a dangerous function because it doesn't nul terminate on overflow. The danger is that it's named misleadingly (str* functions otherwise always work in nul-terminated strings). (strcpy is just banned because there's no bounds check, and they want to force use of strlcpy instead).

strncpy also has the dubious behavior of zero-filling out to N even if strlen(src) is much shorter than N.

Re: Git's list of banned C functions

#400

Post by KptMarchewa »

nanagojo wrote: post #331
paganel wrote: post #267

Earlier quoted context omitted.

This heavily filters for people who have had experience with programming in high-school or even before that, there's no way for a programming novice to pass that grueling routine. And then people rhetorically ask themselves why students coming from economically disadvantaged households are under-represented in this industry (one of the best paying industries in this time and age). Stuff like that has got to change.

> one of the best paying industries in this time and age Medicine is still better paid and better paid universally. Silicon valley is really the outlier here, most of Europe and the world programmers don't get paid that much in comparison.

Software development is usually better paid in Poland than medicine. Medicine starts to pay good way later in life, and only in certain specialisations.
Post reply on HN