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

471–480 of 639 posts

Re: Git's list of banned C functions

#471

Post by badsectoracula »

DaiPlusPlus wrote: post #427
badsectoracula wrote: post #361

Earlier quoted context omitted.

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

> disable that useless compiler output pollutio The compiler is trying to help you write better code - suppressing warnings should not be taken lightly.

This is not the same as the regular warnings though, what Visual C++ is doing isn't helping writing better code - it is suggesting to replace standard functions which are available everywhere in code where i actually know what i'm doing with functions that are available to Visual C++ and pretty much nowhere else.

As i wrote in another comment, something that may lead to issues isn't the same as something that will always lead to issues - e.g. if i check a string's length or actually calculate and allocate the necessary memory before calling strcpy it is perfectly fine and safe to use it, but Visual C++ doesn't know about that, it complains like some stupid greenhorn that read somewhere "never use gotos" and then is surprised when he sees some Linux kernel code with gotos everywhere for cleanup, thinking that those people writing the kernel do not know what they're doing.

Re: Git's list of banned C functions

#472

Post by remexre »

lmilcin wrote: post #388
wongarsu wrote: post #383

Earlier quoted context omitted.

> Also doesn’t the OS lie? I thought the memory wasn’t really physically assigned until first use. That depends on the OS. Linux lies (overcommits), Windows doesn't. In embedded it's more typical to have a special OS like VxWorks or FreeRTOS that don't lie to you, or to have no OS at all (like basically every arduino project)

Linux doesn't lie, it is just probably not doing what your simplified view of memory allocation is. On Linux memory allocation is basically assigning range of address that may or may not be backed by pages in physical memory. This allows doing a lot of interesting and useful stuff. If you really want the memory for some reason (for example you need to guarantee your operation finishes without running out of memory),…

On my machine, which to my knowledge hasn't had this setting changed, ulimit -l reports each process can only lock 64KiB of memory... I feel like "you should use mlock()" isn't really practical advice.

Re: Git's list of banned C functions

#473

Post by yholio »

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

Whenever I review C code, I first look at the string function uses. Almost always I'll find a bug. It's usually an off by one error dealing with the terminating 0. It's also always a tangled bit of code, and slow due to repeatedly running strlen. But strings in BASIC are so simple. They just work. I decided when designing D that it wouldn't be good unless string handling was as easy as in BASIC.

In the case of C, it's a design decision Denis Ritchie made that came down to the particular instruction set of PDP-11, that could efficiently process zero terminated strings.

So a severely memory limited architecture of the 70s led to blending of data with control - which is never a safe idea, see naked SQL. We now perpetuate this madness of nul-terminated strings on architectures that have 4 to 6 orders of magnitude more memory than the original PDP-11.

It's also highly inefficient, because a the length of string is a fundamental property that must me recomputed frequently if not cached.

Bottom line, unless you work on non-security sensitive embedded systems like microwave ovens or mice, there is absolutely no place for nul-terminated strings in today's computing.

Re: Git's list of banned C functions

#474

Post by ineedasername »

lvs wrote: post #257
kazinator wrote: post #198

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. But if you keep up the good work you will one day go from extern void *lecturer; to static const lecturer;

More commonly volatile unsigned short lecturer;

Actually it usually ends up being much simpler than a compiled language. Something like this:

    delete from schema.hr.employee

    where employee.employee_type = 'Lecturer'

    having rownum = cast(dbms_random.value(1,count(*)) as int)
Most Deans' computers have it mapped to alt-delete. They don't even know what it does-- it's just called the "reduce budget function". Which is really unfortunate because when they hit ctrl-alt-delete on a frozen system, but miss the ctrl key by accident, some poor lecturer gets fired and at the end of the semester the Dean says "Huh, wonder where that budget surplus came from.".

Once an entire physics department was disbanded when their Dean's keyboard had a broken ctrl key.

Re: Git's list of banned C functions

#475

Post by wbl »

int_19h wrote: post #335
cletus wrote: post #300

Earlier quoted context omitted.

If I had to choose a language to teach programmers to absolute beginners, I think I'd actually go with Go. I understand the predilection for Python but there are some parts of Python that are just... odd.

There are parts of Go that are similarly odd. Arrays and slices, and the hoops you have to jump through to do something as simple as adding a new item to a list, are very unlike anything else, for example. In Python, the weird stuff is generally easy to avoid/ignore until it's actually needed.

In Java you do the exact same reallocation dance as append does behind the scenes when using arrays.

Re: Git's list of banned C functions

#476

Post by mrweasel »

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)

FAANG engineers are also massively over paid, compared to your average software engineer in any random country.

When people on HN discuses salaries, or I see a job posting from a Silicon Valley company I can't help think that we don't even pay our CTO that much. Frequently you could get two developers for the same price here in Denmark.

Re: Git's list of banned C functions

#477

Post by InvOfSmallC »

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'm not really const. I'm definitely volatile depending on the budget. It's definitely a side gig.

Re: Git's list of banned C functions

#478

Post by mrweasel »

adrianN wrote: post #458
mettamage wrote: post #450

Earlier quoted context omitted.

In The Netherlands this seems to be true. However, as a programmer you can work from home in many cases, especially now. So suppose that a junior psychiatrist makes 5000 EUR gross in NL [1] and a junior developer 2600 EUR gross [2]. A few things though: 1. A psychiatrist has to commute 1 to 2 hours per day. So that salary is not for 8 hours per day, but 9 hours at minimum. Adjusting their salary to an 8 hour basis, i…

At what age are you a junior developer and at what age are you a junior psychiatrist in NL? A bachelor's developer could be as young as 21 I guess, but at least for most jobs in medicine you can't work independently until much later. Maybe it's different for psychiatry?

Junior developers aren't really a thing in many places. They're just developers.

Re: Git's list of banned C functions

#479

Post by ineedasername »

MikeTheGreat wrote: post #463
kbenson wrote: post #438

Earlier quoted context omitted.

Not if they're tenured. Then you can assume they'll never move.

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 stuff that you don't."

Mostly they still just call me professor and I feel awkward every time.

Re: Git's list of banned C functions

#480

Post by a1369209993 »

coliveira wrote: post #232
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…

Null terminated strings are remnants of an era when computers had little memory available. So, at the time it seemed smart to discard the length field and use a single byte-sized terminator (null). If you are writing an operating system for a machine with little memory to spare, this seems like a good decision. Of course things are very different now when memory is not a problem and the goal is safety.

> If you are writing an operating system for a machine with little memory to spare, this seems like a good decision.

Also registers! Especially in syscall interface, consider eg:

  int renameat(int olddirfd,char* oldpath,int newdirfd,char* newpath); /* first example I found that had 2 paths */
If you have registers edx,ecx,esi,edi,ebx available, nul-terminated strings make this fit into:

  edx olddirfd,ecx oldpath,
  esi newdirfd,edi newpath
If you need separate length fields, there simply aren't enough registers:

  edx olddirfd,ecx oldpath.ptr,esi oldpath.len,
  edi newdirfd,ebx newpath.ptr,??? newpath.len
Post reply on HN