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

481–490 of 639 posts

Re: Git's list of banned C functions

#481

Post by lelanthran »

nostrebored wrote: post #469
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 has been more poorly paid than FAANG software engineering in the last two places I've lived (South Africa, Australia)

> Medicine has been more poorly paid than FAANG software engineering in the last two places I've lived (South Africa, Australia)

Interesting. I'm in South Africa, right now. The largest offer for a senior C# dev *right now* on www.pnet.co.za is R960k/a.

Twelve years ago, the GP that I was dating, who worked in a *state hospital* (i.e. not making as much as she could have in private practice) was making more than that.

I don't believe that doctors' salaries over the last 12 years have effectively been lowered. OTOH, if you know of places where they are offering more than R1.8m/a for senior developers, then by all means give me their contact details.

Re: Git's list of banned C functions

#482

Post by thisrod »

ineedasername wrote: post #479
MikeTheGreat wrote: post #463

Earlier quoted context omitted.

Minor detail: lecturers don't get tenure. The job role of 'professor' may be able to get tenure (I think these roles usually do) but 'lecturer' really means 'full time temporary teacher, with a contract for a specified amount of time.

I occasionally adjunct. What students call me at the beginning of the semester is always awkward: Them: "Hello Professor" Me: "Technically I'm not a professor." Them: "Okay, we'll just call you Doctor." Me: "Yeah, about that... not a doctor either." Them: "So why are we paying you?" Me: "Technically, you're paying the school. And the school is paying me... very little" Them: "Answer the question" Me: "Because I know…

I teach first-years in Australia, where boys from private schools call me "sir". When I'm feeling mean, I tell them to drop and give me ten pushups.

Re: Git's list of banned C functions

#483

Post by rtpg »

AaronFriel wrote: post #386
rtpg wrote: post #384

Earlier quoted context omitted.

The string stuff is kind of the original sin, but to be honest almost all programming environments have massive footguns when it comes to times/dates. Python's datetime story is _extremely_ painful to deal with. Try doing .... I dunno, anything apart from getting the current time and doing an ISO format of a Javascript Date object. I think stuff has kinda gotten better, but while Unicode had emoji to kinda save the d…

Python's dates are very unlikely to cause quadratic or exponential performance dips, segfaults, or remote code execution vulnerabilities. (And JS now has Date#toISOString, since ES5.) C's string manipulation functions are a regular source of the worst vulnerabilities in software. Even if they're in the same category of legacy cruft, they're not even remotely in the same magnitude of consequences.

I think you misread my message, I was saying that "time stuff is messed up everywhere", not "python's time stuff is like C's string stuff". The C string stuff is a mess.

I was also saying that JS dates _can_ generate ISOStrings. But good luck doing any serious manipulation without issues. Hell, there isn't even a `strftime` equivalent for JS dates! And so much stuff ends up going through locales that you can't rely on it for machine transformations.

I would be careful about ascribing the quadratic perf discussion to be a C thing though.... I find loads of "accidentally quadratic" stuff in loads of languages all the time. People are really bad about this (lots of confusion between "this is built-in to the data structure" and "this is cheap").

Anyways, yeah. Strings are uniquely awful. Other C APIs suffer from issues, but I find those issues are on par with other language thing. Granted, it's sometimes _because of C_ that other languages suffer from the issues (by relying on C layers for the logic).

Re: Git's list of banned C functions

#484

Post by paavohtl »

IgorPartola wrote: post #295
ironmagma wrote: post #146

Earlier quoted context omitted.

I agree in principle but think these security-focused C developers are focusing on the trees for the forest. Every developer having the responsibility of cultivating their own pet list of banned functions is, frankly, NOT the way to achieve security. Those things need to be enforced at the widest level possible (OS, or language) to have the needed effect.

Two ways to look at it. If I told you that your computer or phone could run the same OS and all the same programs but at 1/10th of the speed so that certain classes of bugs could be eliminated, would you make that switch right here and now? I don’t mean theoretically I mean the device you are looking at right now. If not, would you do that in a year? On the other hand, Moore’s law and all that. Computers will get fas…

You're ignoring the fact computer science has advanced since the 1970s when C was created. C is not full of footguns because that's the only way to build a fast language, it's unsafe because it's old and full of legacy baggage. Modern systems languages (primarily Rust, and to a lesser extent Zig) are on par with C in terms of performance, yet eliminates entire classes of potential safety bugs. Rewriting of course has a (major) cost, but I don't think the argument that using C is somehow inevitable in order to get fast code holds any water.

Re: Git's list of banned C functions

#485

Post by fho »

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.

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.

Re: Git's list of banned C functions

#486

Post by moonchild »

ufo wrote: post #397
moonchild wrote: post #273

Earlier quoted context omitted.

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.

Bounds checking can be done, and it doesn't need any special language features. Tcc does it, as do some of the sanitizers (present in gcc and clang).

Re: Git's list of banned C functions

#487

Post by A4ET8a8uTh0 »

ineedasername wrote: post #479
MikeTheGreat wrote: post #463

Earlier quoted context omitted.

Minor detail: lecturers don't get tenure. The job role of 'professor' may be able to get tenure (I think these roles usually do) but 'lecturer' really means 'full time temporary teacher, with a contract for a specified amount of time.

I occasionally adjunct. What students call me at the beginning of the semester is always awkward: Them: "Hello Professor" Me: "Technically I'm not a professor." Them: "Okay, we'll just call you Doctor." Me: "Yeah, about that... not a doctor either." Them: "So why are we paying you?" Me: "Technically, you're paying the school. And the school is paying me... very little" Them: "Answer the question" Me: "Because I know…

I don't think you should feel awkward. I refer to all my teachers in emails as professor ( unless I want to list more detailed honorifics ). My current analytics guy is clearly very smart, seems to be in that adjunct zone, but I address him as professor out of sheer respect.

Re: Git's list of banned C functions

#488

Post by sas41 »

kazinator wrote: post #198
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 teach at university as external lecturer. Teaching strings in C is the hardest thing I have to do every time. But if you keep up the good work you will one day go from extern void *lecturer; to static const lecturer;

I can confirm, this is exactly what happened to me.

Re: Git's list of banned C functions

#490

Post by tlavoie »

867-5309 wrote: post #454
mjcohen wrote: post #444

Earlier quoted context omitted.

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.

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

Post reply on HN