Live data from Hacker News

Git's list of banned C functions

github.com

451–460 of 639 posts

Re: Git's list of banned C functions

#451

Earlier quoted context omitted.

> I don't really get the correlation between household income and programming experience in high school. > Their parents can't afford a laptop? Holy crap, the amount of privilege shown off in just two sentences is absolutely astounding. This may come as a shock to you, but a very significant number of people don't have a couple hundred dollars to buy a low-end used laptop. 40% of Americans would struggle to come up w…

> 40% of Americans would struggle to come up with $400 for an emergency expense [0], let alone save $400 for a laptop. It actually doesn't say that, it says they don't have $400 in cash equivalents but may be able to produce it by selling "assets". So a person who keeps all their savings in CDs or investments also counts, although only for expenses you can't put on credit cards.

Only 19% of the people who could not be able to pay cash or its equivalent said they would be able to sell something. 29% said they would be unable to pay.

Figure 12 on page 21 of the underlying report - https://www.federalreserve.gov/publications/files/2017-repor... .

Re: Git's list of banned C functions

#452
post #115

Earlier quoted context omitted.

I didn’t know that it was Microsoft that lobbied for them; that perplexes me since I thought Microsoft’s version of them were a bit different (for example, I think C11’s explicitly fail on overlapping inputs where Microsoft specifies undefined behavior) and because Microsoft didn’t bother supporting C99 for the longest time. (Probably still don’t, since VLA was not optional in C99, IIRC. I think Microsoft was right t…

VLA syntax can be useful because you can cast other pointers to them - for instance you can cast int* to int[w][h] and then access it as [y][x] instead of [y*w+x]. As a bonus this crashes icc if you do it.

>As a bonus this crashes icc if you do it.

I thought this was a pretty funny thing but unfortunately when I tried this on ICC it seemed to compile just fine.

Though I am amused by one thing: the VLA version generates worse code on all compilers I've tried. Seems to validate the common refrain that VLAs tend to break optimizations. (Surely it's worse when you have an on-stack VLA though.)

Re: Git's list of banned C functions

#453

Earlier quoted context omitted.

But the caller to strnlen() has already provided both the (pointer to the) array and the length! Note that C99 does permit declaring a VLA in the body of the function: char *strndup(size_t n; const char *s[n], size_t n) { char buf[n]; /* alloc a temporary VLA */ assert(sizeof(buf) == n); /* yep! */ assert(sizeof(s) == n); /* nope, sizeof(s) == 1 */ } So there's absolutely no reason (other than being in violation of t…

With standard VLAs, you always have a guarantee of being able to access sizeof(buf) bytes from buf, for any variable buf. With your syntax, that guarantee would no longer hold, unless c had dependent types that could prove said guarantee.

Well, given that C is fundamentally about separate compilation and external linkage, most "guarantees" in the language are really just promises or contracts. As demonstrated in david2ndaccount's comment, standard C already handles VLA function arguments just fine (without any need for dependent types).

The only issue is that C99 insists that the first dimension of an array argument must decay to a pointer, discarding the associated type information of that array's dimension.

Re: Git's list of banned C functions

#454

Earlier quoted context omitted.

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.

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

Re: Git's list of banned C functions

#456

Earlier quoted context omitted.

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.

A lot of it was written in Turbo Pascal, which (among many other things that would have caused Niklaus Wirth to break out in hives) let you include inline machine code (and later, inline assembly language).

That's true, but so did C compilers at the time. And most software didn't actually make use of it - they didn't have to, because Turbo Pascal had e.g. pointer arithmetic as powerful as in C.

But anyway, we were talking about the real world software on microcomputers, not just standards in the abstract. With that in mind, I think TP/BP is a better example of Pascal in the wild than anything Wirth ever made.

Re: Git's list of banned C functions

#457

Earlier quoted context omitted.

> I don't really get the correlation between household income and programming experience in high school. > Their parents can't afford a laptop? Holy crap, the amount of privilege shown off in just two sentences is absolutely astounding. This may come as a shock to you, but a very significant number of people don't have a couple hundred dollars to buy a low-end used laptop. 40% of Americans would struggle to come up w…

> 40% of Americans would struggle to come up with $400 for an emergency expense [0], let alone save $400 for a laptop. It actually doesn't say that, it says they don't have $400 in cash equivalents but may be able to produce it by selling "assets". So a person who keeps all their savings in CDs or investments also counts, although only for expenses you can't put on credit cards.

You can produce a couple 100k by selling a kidney too.

Re: Git's list of banned C functions

#458

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.

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?

Re: Git's list of banned C functions

#460
post #184

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.

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

Seeing valgrind come up with 0 leaks after like 10 hours straight on a lab was such a good feeling
Post reply on HN