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

301–310 of 639 posts

Re: Git's list of banned C functions

#301

Post by zlynx »

user5994461 wrote: post #291
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.

>>> Surely someone could write a better string library in C that hides the complexity. In short, it's not possible to write a nice string library in C because C simply doesn't support objects, and by extension doesn't support libraries. Strings are a perfect example of an "object" in what is later known as object oriented programming. C doesn't have objects, it's the last mainstream language that's simply not object…

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.

Re: Git's list of banned C functions

#302

Post by unnouinceput »

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…

Actually I experienced worse restrictions when I was at Siemens writing embedded. Expanding on your list, here are some extras:

- ternary operator("?") was strictly forbidden. One had to use full "if () {..}else {..}" syntax with comments inside each branch even if the branch was empty

- a dynamic array written in an abstract way, when used and implemented specifically for current project had to become a constant static one, with values precalculated and copy/pasted to current project source. This was a fun one to do maintenance work years later.

- magic numbers inside code was forbidden. All numbers had to be defined in a specific header, with explanation why is that number said value.

- no variable parameters. All functions to have fixed parameters

- use of macros as minimum as possible. Code review was wasted sometime on 50% time over use of macros that were not already "classic" from the project point of view

- operator overload strictly forbidden. Also overloading functions was forbidden too.

Re: Git's list of banned C functions

#303

Post by watersb »

Gibbon1 wrote: post #94
SavantIdiot wrote: post #57

Earlier quoted context omitted.

If you list the languages you use, I'd be happy to point out the "footguns" in each of them. For all the warts on C, there really is no language that can compete for what it has accomplished over ~50 years. Recall that during the rise of C, people were writing machine code on punch cards. Assembly -> Machine code has far more footbullets than C, it is a tradeoff between hand holding and tiny fast code. Wow, this blew…

My favorite assembly foot gun was a guy I worked with had a cute routine. You had a call to the routine, followed by a null terminated string after that. The routine would spit the string to the terminal. And then return to the location after the string. He had some bug where in one place it returned to the start of the string, executed it, and kept going. The end result just happened to be a nop. Had been like that…

And when you fix it, everything breaks.

Re: Git's list of banned C functions

#304

Post by astrobe_ »

chris_wot wrote: post #168
adrianmonk wrote: post #97

Earlier quoted context omitted.

> Why not check the git history? Because that is effort every person who uses the file has to do over and over again, whereas maintaining the file is effort that has to be done once by one person.

It sounds like you want a manual. Personal preference I guess. The maintainers seem to have decided to keep it in the history. It's not like this was ever meant for anything other than git itself.

If all you have is Git everything looks like a commit.

Re: Git's list of banned C functions

#305

Post by [deleted] »

young_unixer wrote: post #279
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.

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?

[deleted]

Re: Git's list of banned C functions

#306

Post by c-cube »

austinl wrote: post #145
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.

Most of the C I wrote was while in college. I think understanding the question, "why are strings in C hard?" is a good gateway to understanding how programming languages and memory work generally. I agree with you though that teaching C as introductory is probably not the best — our "Programming in C" course was taken in sophomore year. I wouldn't want to use it my day job, but I'm glad that it was taught in universi…

It's also because other languages have better designed strings. D, go, rust, etc. have pointers too but their string handling is based on slices and arrays, which are approximately 10,000 times less footgunny.

Re: Git's list of banned C functions

#307

Post by watersb »

xondono wrote: post #89
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…

Anything enforcing MISRA has essentially (almost) no way of allocating memory at runtime.

MISRA: "Motor Industry Software Reliability Association"

https://en.m.wikipedia.org/wiki/MISRA_C

Re: Git's list of banned C functions

#308

Post by cblconfederate »

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

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.

Re: Git's list of banned C functions

#309

Post by user5994461 »

zlynx wrote: post #301
user5994461 wrote: post #291

Earlier quoted context omitted.

>>> Surely someone could write a better string library in C that hides the complexity. In short, it's not possible to write a nice string library in C because C simply doesn't support objects, and by extension doesn't support libraries. Strings are a perfect example of an "object" in what is later known as object oriented programming. C doesn't have objects, it's the last mainstream language that's simply not object…

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.

Re: Git's list of banned C functions

#310

Post by c-cube »

user5994461 wrote: post #291
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.

>>> Surely someone could write a better string library in C that hides the complexity. In short, it's not possible to write a nice string library in C because C simply doesn't support objects, and by extension doesn't support libraries. Strings are a perfect example of an "object" in what is later known as object oriented programming. C doesn't have objects, it's the last mainstream language that's simply not object…

Strings have nothing to do with objects. You can write a string library, eg. [sds](https://github.com/antirez/sds). It's just not standard.
Post reply on HN