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

411–420 of 639 posts

Re: Git's list of banned C functions

#411

Post by Cullinet »

rodgerd wrote: post #74
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…

There's far more critical code in the world running on COBOL and s3[79]0 assembler. COBOL is vastly more important than C.

but there's a significant albeit rarely seen or sought for ecosystem for managing software on mainframes the source to which is long lost and the authors deceased and the the machine code is what you have to work with. you can't describe the work as being attractive, but the tooling which exists is first class and has been keeping the world turning safely for a good half century I'd say in reality...

Re: Git's list of banned C functions

#412

Post by golergka »

Gene_Parmesan wrote: post #348
unbalancedevh wrote: post #249

Earlier quoted context omitted.

It always makes me wonder if there's some hidden overhead that I'm absorbing. When I program in C I feel like I know a lot better what the generated instructions will be. Using higher-level languages for embedded programming where resources are tight makes me uncomfortable.

In addition to the overhead from dyn alloc and the GC as someone else mentioned, there is also the size overhead that comes with every object in an OO language. The obj overhead for Java is JVM-dependent, but I believe it to be somewhere around 16 bytes. A mostly unrelated stackoverflow post I found[0] states that an empty standard string in Java occupies 40 bytes due to the normal object overhead and overhead relate…

In cases where perfomance actually matters, you usually have other tools, like StringBuilder in C#. But in my experience, 99% of code that works with dynamic strings is not perfomance-sensitive, but is often very correctness-sensitive and readibility-sensitive.

Re: Git's list of banned C functions

#413

Post by closeparen »

lmilcin wrote: post #365
closeparen wrote: post #181

Earlier quoted context omitted.

How often does the dynamic allocation rule lead to an ad-hoc allocator appearing inside the program? Also doesn’t the OS lie? I thought the memory wasn’t really physically assigned until first use.

Why would you want to implement your own allocator? The goal of these rules is to improve reliability and timeliness of your application. If you intend on working around those rules to do what the rules explicitly forbid then either you or the rules are wrong.

Suppose your problem intrinsically has variable numbers of variable size records coming and going at runtime. Sure you can allocate a big array upfront. But it seems to me that the code which directs records to slots in this array is an allocator.

Re: Git's list of banned C functions

#415

Post by Cullinet »

burnished wrote: post #187
mkipper wrote: post #86

Earlier quoted context omitted.

citation needed I'm sure there's a lot of important things that rely on COBOL, but by most definitions of "critical", I think this is way off the mark.

COBOL is still used in many banking systems such as ATMs. These are 'critical' systems by most any definition of the word 'critical'.

take a look at VMS to behold how elegantly and seamlessly we wrote software in whichever language suited the task most appropriately, barely conscious of the concept of foreign functions being a horror story for future generations instead of being entirely standard and letting us switch from BLISS to Pascal to ADA and C and C++ and DEC BASIC and throw in a few DCL macros or optimize the compilers to which source was of course provided and so that's how we delivered really rather efficient programs, really, in LOC, since nobody was hammering square pegs into semantic round holes or chasing effects when you needed to manage types intrinsically to your critical path routines but didn't need to extend the type system throughout your code base because RDB quaintly would let you call it in FORTRAN and get down to typology from the elements of mathematical sets themselves if you must, nicely isolated and ACID wrapped with system wide cluster transaction management available for everything and everyone's needs and the filesystem designed orthogonal to the database letting you think of your data in a single unified concept with primordial os level guarantee of data integrity for corollary sanity checking

Re: Git's list of banned C functions

#416

Post by lmilcin »

xxpor wrote: post #398
lmilcin wrote: post #394

Earlier quoted context omitted.

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

If you want to "allocate" (reserve) physical memory just call malloc and then mlock. No lie. You get physical pages or error.

Get over it. What you call "allocation" is two distinct operations on Linux, one of which is called malloc in standard c library, unfortunately, and that's where your confusion comes from.

Re: Git's list of banned C functions

#417

Post by jorl17 »

capableweb wrote: post #136
jorl17 wrote: post #125

Earlier quoted context omitted.

I find it highly backwards that documentation on "what to use instead of X" is in the commit message disabling X. One _might_ do it and might remember to do it, but IMO it makes absolutely no sense for this not to be documented properly in code, as suggested by OP. By that logic, a non-insignificant amount of (good) comments in code could be removed and people asked to "git blame the code and check out the commit tha…

> By that logic, a non-insignificant amount of (good) comments in code could be removed and people asked to "git blame the code and check out the commit that made it for the documentation". Of course this could be done, but it sounds ridiculous even typing it out. Yes, exactly. You want to understand how a codebase changed and evolved over time? Git is your friend. If you want the facts of the code today? The source…

> Yes, exactly. You want to understand how a codebase changed and evolved over time? Git is your friend. If you want the facts of the code today? The source code is your friend.

100% agree. Though I don't mind if comments also leave historical information about the code. Can't be too much -- there is a delicate balance.

Do note, however, that you said it yourself: If you want the facts of the code today, go to the source code. In my opinion, the "facts of the code of git" are that functions X,Y,Z are "banned", but the code does not tell me why, or what to use instead. It just bans them. I would expect to see something in the code, not (just) in a git commit. It's also not that I can't google these functions (a couple of minutes will answer these questions), or that I should be experienced enough to know why they're evil, it's that it's IMO a reasonable, developer-friendly and good thing to do.

Re: Git's list of banned C functions

#418

Post by throw0101a »

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

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

It was considered:

> C designer Dennis Ritchie chose to follow the convention of null-termination, already established in BCPL, to avoid the limitation on the length of a string and because maintaining the count seemed, in his experience, less convenient than using a terminator.[1][2]

* https://en.wikipedia.org/wiki/Null-terminated_string#History

Richie et al had experience with the B language:

> In BCPL, the first packed byte contains the number of characters in the string; in B, there is no count and strings are terminated by a special character, which B spelled *e. This change was made partially to avoid the limitation on the length of a string caused by holding the count in an 8- or 9-bit slot, and partly because maintaining the count seemed, in our experience, less convenient than using a terminator.

* https://www.bell-labs.com/usr/dmr/www/chist.html

Re: Git's list of banned C functions

#419

Post by jorl17 »

orf wrote: post #144
capableweb wrote: post #131

Earlier quoted context omitted.

Your source code should describe what the program should do today. It should not contain all historical artifacts about your source code, as it'll grow to big and unmanageable then. Instead, use Git to store temporal information, data that is about change and reasoning behind it. Git is basically a timeline, instead of hard facts of today. That's why it makes sense to describe the background and reasoning behind a ch…

Totally agree, which is why nobody is suggesting adding the background and reasoning behind the change to the source file as a comment. They are suggesting adding a more informative error, which may include a subset of that background and reasoning. An error message that points you to the functions you should use instead is infinitely more informative than one that says “this is banned. Bye.”

Precisely.

Re: Git's list of banned C functions

#420

Post by ericbarrett »

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.

Very true, but if you're teaching CS then this also exposes students to the topic of ownership-versus-reference in a much gentler way than C.
Post reply on HN