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

351–360 of 639 posts

Re: Git's list of banned C functions

#351

Post by selfhoster11 »

michaf wrote: post #247
selfhoster11 wrote: post #199

Earlier quoted context omitted.

The funny thing is that you can just use the topmost bit of the length to indicate that the string length is >127, and chain as many length bytes as you want before you begin the string proper (to save space). It would be still a better encoding than a null at the end.

This way you would trade in a null-byte-terminated variable length string for essentially a null-bit-terminated variable length number (plus the remaining string). I am not convinced that this actually would be much safer.

Unicode does variable length bit strings too, so I'm not a visionary or anything. It would be safer for no other reason than that such a pattern could only occur at the start of the string, with zero special handling, while a null could occur anywhere in a zero-terminated string.

Re: Git's list of banned C functions

#352

Post by onei »

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?

In the UK, every student does Math, English and Science to a basic level. Maths and English in particular were held up as non-negotiable if you ever wanted a job, I suspect so you had a reasonable level of literacy and numeracy to be able to count money, read letters, etc.

Conversely, programming was not available in my fairly middle-class school. In terms of money, we only have to look to the laptops schools are providing to students (or not depending on government funding) to see how many children don't have access to a laptop. A good place to learn can also be hard to find for large families in small houses which is sadly all too common for low income households.

Re: Git's list of banned C functions

#353

Post by selfhoster11 »

pertymcpert wrote: post #266
michaf wrote: post #247

Earlier quoted context omitted.

This way you would trade in a null-byte-terminated variable length string for essentially a null-bit-terminated variable length number (plus the remaining string). I am not convinced that this actually would be much safer.

This is just the LEB128 format, which is used commonly used and I don't think there's any serious problems with it.

Interesting. Thank you for sharing this!

Re: Git's list of banned C functions

#354

Post by lcuff »

young_unixer wrote: post #333
_underfl0w_ wrote: post #299

Earlier quoted context omitted.

> 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? All of the above, and it's surprising this isn't obvious. It may be hard to notice or internalize if you've never seen it and only know privilege, but possession of all or even some of those things is not a guarantee for everyone. Believe it or not, there are…

It isn't obvious to me because I've never lived in the US. I was genuinely asking, not trying to shame people who can't afford a computer. Maybe I didn't use the right words to formulate my question.

Thanks for clarifying the context of your question. Very helpful, and changes the tone completely. 1/2 of the people in the U.S. "don't pay taxes", that is, don't make enough money to owe taxes. So that's one issue. I mentor a hispanic kid who's mother's English was so weak and her knowledge of 'the system' so weak, that she couldn't take advantage of programs to provide used computers to her kids, or low-cost Internet access to her household. And the $10/month for low-cost Internet access WAS out of reach. 10 people in a two bedroom apartment was also their norm.

Re: Git's list of banned C functions

#355

Post by selfhoster11 »

ascar wrote: post #286
michaf wrote: post #247

Earlier quoted context omitted.

This way you would trade in a null-byte-terminated variable length string for essentially a null-bit-terminated variable length number (plus the remaining string). I am not convinced that this actually would be much safer.

At least you don't have (obvious) performance problems with it, because you will effectively never need more than 9 (usually 2 or 3) of these bytes. But sure on modern 64 bit systems just using a 64 bit integer makes much more sense. On a small embedded 8 bit oder 16 bit microcontroller it might make sense.

You are correct, I was trying to show that such a scheme was practical even in the early 1980s when zero-termination was beginning to dominate. This could well be used on 64-bit systems (just with a larger word size than a byte), though the utility of such a thing is questionable.

Re: Git's list of banned C functions

#357

Post by int_19h »

Kaze404 wrote: post #294
sudomakeup wrote: post #162

Earlier quoted context omitted.

Why wouldn't it be an issue with a compiled language? Its nearly the exact same reasoning as "we're not going to break older websites"

In Javascript there's an expectation that Javascript written 15 years ago for Netscape will also work on Firefox 89. Is that also the case with C, wrt compiler versions? I've always assumed it wasn't.

It's very much the case, so long as you stick to standard C (the full limitations of which very few people are actually aware of).

Runtime backwards compatibility is similarly extensive on platforms that care about it. You can still take a DOS app written in ANSI C89 the year that standard was released, and run it on (32-bit) Windows 10, and it'll work exactly the same. In fact, you can do this with apps all the way back to DOS 1.0.

Re: Git's list of banned C functions

#358

Post by cynoclast »

paganel wrote: post #267
orwin wrote: post #184

Earlier quoted context omitted.

In my school, we had two days to understand the basics of text editors, git (add, commit, rebase, reset, push) and basic bash functions (ls, cd, cp, mv, diff and patch, find, grep...) + pipes, then a day to understand how while, if/else and function calls work, then a day to understand how pointer work, then a day to understand how malloc(), free() and string works (we had to remake strlen, strcpy, and protect them).…

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.

My professor (head of CS dept) referred to these as 'weed out classes'.

If that sounds evil, imagine the grief, wasted money, time, frustration, and stress of letting people get 3-4 years into computer science and then dropping out because it's fucking hard.

So my second hardest classes were freshman year. 3rd year (micro-architecture and assembler)finally bested them.

Re: Git's list of banned C functions

#359

Post by int_19h »

SavantIdiot wrote: post #57
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.

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…

Consider the fact that Simula-67, which predated C by 3 years, had classes and objects very similar to what Java offers (and then some - e.g. coroutines), and a built-in string processing library that used object-oriented syntax.

The reason why C won had little to do with its advantages as a language over the competitors. It just happened to be the systems language for Unix, which was the winner in the early OS wars on microcomputers (for unrelated reasons). Once it became so established, there was a positive feedback loop: you would write portable code in C, because you knew that it was the fastest language that most platforms out there would support. And then any new platform would offer a C compiler, because they wanted to be able to run all the existing C code out there. And so, here were are.

Re: Git's list of banned C functions

#360

Post by int_19h »

JoeAltmaier wrote: post #178
eschaton wrote: post #73

Earlier quoted context omitted.

This is a grossly inaccurate description of computing at the time of the rise of C. C was competing with Pascal/Modula, BLISS, PL/I, BCPL, and so on, not assembly on punched cards. The “C competing with assembly” meme was very specific to microcomputer game and operating system development, not more general microcomputer application development, and not to minicomputer or mainframe development.

Mainframes very quickly were outclassed by minicomputers. They could not respond quickly to technology changes as fast. C was indeed king for decades.

C was not without competition on microcomputers, either. A lot of DOS software was written in Pascal, for example - and it wasn't any slower for that.
Post reply on HN