Anybody know where Dan Pop went and what he's up to these days?
Tell HN: C Experts Panel – Ask us anything about C
801–810 of 978 posts
Re: Tell HN: C Experts Panel – Ask us anything about C
#802It is 2020. You are looking at a series of projects your company has teed up. All are greenfield efforts - no legacy. What would be the attributes of a project that would have you recommend C as the programming language?
Anything high performance: game engine, scientific computation, deep packet inspection, image analysis, machine learning, rendering engines, high frequency trading.... The list is long!
AFAIK, few seem to choose C for game engines or rendering engines. Not familiar with the other domains.
Re: Tell HN: C Experts Panel – Ask us anything about C
#803Yeah, I don't program much in C and I don't have a question. I'm here just to congratulate everyone involved for this amazing thing. It's awesome to see people take the time to help each other. Nice job!
Re: Tell HN: C Experts Panel – Ask us anything about C
#804Earlier quoted context omitted.
> …what would the impact be if the compiler assumed (correctly) that the loop might not terminate? Loaded question—the compiler is absolutely correct here. There are two viewpoints where the compiler is correct. First, from the C standard perspective, the compiler implements the standard correctly. Second, if we have a real human look at this code and interpret the programmer’s “intent”, it is most reasonable to assu…
Thanks for the code, this is exactly the kind of concrete example I was looking for! You're correct about how it behaves with "int" and "unsigned", very interesting. But it occurs to me that on x64 we'd probably want to use 64-bit values. If I change your typedef to either "long" or "unsigned long" that seems to give me the SSE version of the code! (in x86-64 gcc 9.3) Why should longs behave so differently from ints?…
> But does the design of C really help here, or are there ways it could help more?
I’m sure there are ways that it could help more. But you have to find an improvement that is also feasible as an incremental change to the language. Given the colossal inertia of the C standard, and the zillions of lines of existing C code that must continue to run, what can you do?
What I don’t want to see are tiny, incremental changes that make one small corner of your code base slightly safer. Most people don’t want to see performance regressions across their code base. That doesn’t leave a lot of room for innovation.
> It all seems dangerously fragile.
If performance is critical you run benchmarks on CI to detect regression.
> It's the second part that seems really risky.
It is safer than the alternatives, unless you write it in a different language. The “fast” code here is idiomatic, simple C the way you would write it in CS101, with maybe a couple builtins added. The alternative is intrinsics, which poses additional difficulty. Intrinsics are less portable and less safe. Less safe because their semantics are often unusual or surprising, and also less safe because code written with intrinsics is hard to read and understand (so if it has errors, they are hard to find). If you are not using intrinsics or the autovectorizer, then sorry, you are not getting vector C code today.
This is also not, strictly speaking, just an HPC concern. Ordinary phones, laptops, and workstations have processors with SIMD for good reason—because they make an impact on the real-life usability of ordinary people doing ordinary tasks on their devices.
So if we can get SIMD code by writing simple, idiomatic, and “obviously correct” C code, then let’s take advantage of that.
Re: Tell HN: C Experts Panel – Ask us anything about C
#805Earlier quoted context omitted.
There are rules and requirements documented in the spec, and there are de-facto rules and requirements that programs expect. Not only that, but when they do exploit these rules, often the code generated is obviously incorrect, and could have been flagged at compile time. Right now, it seems like compiler vendors are playing a game of chicken with their users.
I think the issue is that many of these "obviously incorrect" things are not obvious at the level that the optimizations are taking place. Perhaps it would be worth considering adding higher-level passes in the compiler that can detect these kinds of surprising changes and warn about them.
Well, no, the issue is that the compiler writers refuse to acknowledge the these obviously incorrect things are incorrect in the first place and tend to blame users for tripping over compiler bugs. If it were just that they didn't know how to fix said bugs, that would be a qualitatively different and much less severe problem.
Re: Tell HN: C Experts Panel – Ask us anything about C
#806Earlier quoted context omitted.
Does it concern you how aggressively compiler teams are exploiting UB?
You do have to understand that compiler teams aren't saying something like "this triggers UB, quick just replace it with noop." It's just something that naturally happens when you need to reason about code. For example, consider a very simple statement. let array[10]; let i = some_function(); print(array[i]); The function might not even be known to the compiler at compilation time if it was from a DLL or something. B…
> ["]I can use that information!"
Yes, that is a perfect example of buggy compiler handling of undefined behaviour. A non-buggy compiler would either behave in a manner chacteristic of the environment (ie read address array+i), ignore the situation entirely (which also results in reading array+i), or (preferably) issue a error to the effect of "possible array access out of bounds, suggest 'assert(i<10);' here".
Re: Tell HN: C Experts Panel – Ask us anything about C
#807Earlier quoted context omitted.
Curious what were the requirements to select C as a first high school language over many other choices? I imagine there's a balance of practicality (after the class), and then the usual questions about tooling, sharp edges, and ease of learning.
It's a three year rotation: Python, C (Unix), C (Arduino). My goal with the class is to teach ideas that will stand the test of time. C (and Unix) certainly fit that bill. Happily, the tooling is the easiest part. Every student has a rasberry-pi running debian, no mouse, no window server, and no extraneous software. You can spool kids up on a nano-based C toolchain in one class period with remarkably few sharp edges.…
Neat! I think your choice of C and Python as the languages to be taught is very right. The idea of showing the use of C in both Desktop/Server and Embedded environments has long been the approach i had advocated. C is truly the de-facto "universal" language and students should be made aware of it from the start.
I would suggest the following additions;
* The Arduino "language" is C++. Use this as a gentle introduction to C++ as a "better C". From there you can move on to proper C++ (do NOT teach "Modern C++" in the beginning). The intent is to show how "C + some syntactic sugar for expressing abstractions" is quite powerful and that is what is C++. This should prepare the students to embark on a proper study of C++.
* Instead of using the Arduino "language+library" through the IDE, show them how to use the same GNU gcc toolchain to program the MCU directly in C. See Make: AVR programming by Elliot Williams for details. This teaches the students the idea of a "cross compiler toolchain" and all other related matters from first principles.
Re: Tell HN: C Experts Panel – Ask us anything about C
#808Earlier quoted context omitted.
Most of the useful optimizations that could be facilitated by treating integer overflow as jump the rails optimization could be facilitated just as well by allowing implementations to behave as though integers may sometimes, non-deterministically, be capable of holding values outside their range. If integer computations are guaranteed never to have side effects beyond yielding "weird" values, programs that exploit th…
How is this better behavior?
It lets you check that a+b > a for unknown unsigned b or signed b known > 0, to make sure addition didn’t overflow. I’m rather certain all modern C compilers will optimize that check out.
Re: Tell HN: C Experts Panel – Ask us anything about C
#809Earlier quoted context omitted.
When I wrote that, I had in mind the observation about continued recalculation of buffer len. My suggestion has no such thing. It looks so good that I imagine this was probably how it was intended to be used. With that in mind, isn't it the user's job to know the size of the buffers he's using? Doesn't expecting that the function know about buffer size go against the single responsibility principle? I'm new to C, in…
The problem in practice is that you do not write “hello” and “world” to the destination buffer. You write data that is computed more or less directly from user inputs. Often a malicious user. So the user only needs to find a way to make the data longer than the developer expected. This may be very simple: the developer may have written a screensaver to accept 20 characters for a password, because who has a longer pas…
I think sprintf and gets can be perfectly secure interfaces. The standard just needs to specify them in a way that causes overflows to raise signals. This is probably more for POSIX and UNIX, since I think it requires the concept of memory mappings. For example:
Start by specifying that memcpy goes by increasing address. This can be done by specifying that no pages to be written by memcpy can be written to until after all pages with lower addresses have been accessed by memcpy. (it is OK to read forwards and then write backwards; the first access must not skip pages)
Next, specify sprintf and gets in terms of memcpy. The output is written as if by memcpy.
The user may then place a PROT_NONE page of memory after the buffer. Since the pages are being accessed by address order, the PROT_NONE page will safely stop the buffer overflow. The user can have a signal handler deal with the problem. It can exit or map in more memory. If we require sprintf and gets to be async-signal-safe, then the signal handler can also siglongjmp out of the problem.
Re: Tell HN: C Experts Panel – Ask us anything about C
#810I want this feature in the standard.
If there exists any memory block allocated using malloc() / calloc() / realloc() which has not been free()'d, at the end of the program, they would be free()'d automatically.
One can easily do it with keeping a linked list and using atexit(), but, can it be added to the standard?
A general question, will anything, any feature, which is "easy" to implement in pure C, like array knowing its own length or pascal strings, NOT be allowed to be in C standard, even if it is widely used, maybe almost everywhere?