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

521–530 of 639 posts

Re: Git's list of banned C functions

#521

Post by dotancohen »

tlavoie wrote: post #490
867-5309 wrote: post #454

Earlier quoted context omitted.

+1 for the PET mention since it was my first "computer". much overlooked in favour of the 64

Ah, yes. I recall the luxury of a Commodore of my very own (a C128), after using PETs in school. We had a whole three of them at the time, with a shared, dual-floppy drive for the set. Naturally, our teacher wisely pushed hard on figuring what you could out on paper first.

  > Naturally, our teacher wisely pushed hard on figuring what
  > you could out on paper first.
Specifically in the case of the Commodores (I grew up on a C128) I find this observation backwards. Sure, if you only had three machines for twenty students then time on the machine was valuable. But on those machines there was so much to explore with poke (and peek to know what to put back). From changing the colours of the display to changing the behaviour of the interpreter.

I think that I discovered the for loop at eight years old just to poke faster!

Re: Git's list of banned C functions

#522

Post by maccard »

mjcohen wrote: post #447
nanagojo wrote: post #331

Earlier quoted context omitted.

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

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

In the US. In many other places, medicine is an undergraduate field of study, you're in a hospital from your first year, and by year 3 you're being paid.

Re: Git's list of banned C functions

#523

Post by cesaref »

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.

I think the key is to understand the historical context of C, what it was competing with, and what concerns people writing C had.

Compared to the alternative (straight assembler) at the time as a systems programming language, C is a massive step up.

Also, the UNIX way was independent processes, so the APIs did not need to be thread safe, as there was no threading in the target architectures.

Now given the massive amount of existing C out there from the time of such architectures, you either have to move the API and language on to make it incompatible with existing code, or support the old baggage. The language has kept compatibility, and in this case, the github peeps have deprecated APIs using macros, so it's a reasonable approach.

An alternative approach would be to move the language on, but by it's nature it won't be compatible with C, so you give it a new name. You call it things like go, or rust, or swift. These are all C with the dangerous bits removed. It'll be interesting in 40 years time to see if people are having the same conversation about these languages - 'OMG, how did people write stuff in rust? It can't cope with [insert feature of distributed quantum computing]. It's really scary'

Re: Git's list of banned C functions

#524

Post by unnouinceput »

gpanders wrote: post #341
unnouinceput wrote: post #302

Earlier quoted context omitted.

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

All of these except for the first two seem like good rules in general. Was the ban on the ternary operator just a style/readability thing?

Maintenance reasons. Future juniors to not have problems diving into projects directly. Chaining several ternary operators in same line is great to showoff your C prowess but a PITA to decipher what was doing, hence the rules.

Re: Git's list of banned C functions

#525

Post by dave84 »

fho wrote: post #485
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.

Question: how do you teach for-loops? That is something I have a hard time convey as a teacher. My problem is that I have done this so long that I have no idea what there is not to understand about loops ... it's such a simple thing. But my (undergrad biology) students regularly have a hard time groking the concept no matter what explanation I use.

Not OP but I'm teaching undergrad C. I'm assuming you have covered while loops before hand, if not, start there and cover the constructs with them that you would normally use a for loop for, example:

  int i = 0; //a
   
  while(i
and introduce for loops as a special case of the while loop:

      //a        //b     //d
  for(int i = 0; i
Then outline situations when you would use a for loop over a while loop, fixed number of repetitions, use with arrays etc.

Re: Git's list of banned C functions

#527

Post by da39a3ee »

cesaref wrote: post #523
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.

I think the key is to understand the historical context of C, what it was competing with, and what concerns people writing C had. Compared to the alternative (straight assembler) at the time as a systems programming language, C is a massive step up. Also, the UNIX way was independent processes, so the APIs did not need to be thread safe, as there was no threading in the target architectures. Now given the massive amo…

This is git, not github.

Re: Git's list of banned C functions

#528

Post by mariusor »

user5994461 wrote: post #344
c-cube wrote: post #310

Earlier quoted context omitted.

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.

The challenge is not to write a string library, but to write a "nice" string library. Let's say, something that's easier to use and doesn't have all the footguns of the char arrays. The library you link doesn't come anywhere close to that. It's 99% like the standard library and it has the exact same issues.

I would love to see what you mean by "exact same issues".

sds strings contain their lengths, so operating on them you don't have to rely on null termination, which (to my knowledge as a lower-midlevel C programmer) is the most prevalent reason why people take issue with C strings.

If you mean that they're not really "strings" but byte arrays I would say that I agree, but to all intents and purposes that's what the C ecosystem considers as strings.

Keeping an API which is very similar to the standard library is also a plus, as it doesn't force developers to change the way they reason about the code.

Re: Git's list of banned C functions

#529

Post by rightbyte »

spc476 wrote: post #448
rightbyte wrote: post #263

Earlier quoted context omitted.

If they would have used a "fat strings" for the standard lib there would have been at least four different types by now with 8 to 64 bit lengths. Maybe even with signed char as length field on some systems, unsigned char on other. Or signed and unsigned for all int:s for a total of 8 types. I think the sentinel character was the best choice in hindsight and at the time in that regard. But I wish the xxx_s versions an…

There are no C standard functions, aside from malloc(), calloc() and realloc(), that have to allocate memory to work. I think that's intentional on the part of the C standard library.

strdup would be one in c22. Maybe they should have done a allocating "stradd" when they were at it ...

Re: Git's list of banned C functions

#530

Post by mariusor »

swlkr wrote: post #122
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'm partial to https://github.com/antirez/sds these days

The only problem I have with antirez's lib is that he didn't make it into a single header library.
Post reply on HN