Tell HN: C Experts Panel – Ask us anything about C • Hacker News Board

Re: Tell HN: C Experts Panel – Ask us anything about C

#781

Post by ender341341 » Wed, Apr 15, 2020, 1:35 AM UTC

qznc wrote: post #524

cwzwarich wrote: post #505

Earlier quoted context omitted.

> This is a common misconception (or poor way of phrasing it, sorry). Compiler implementers don't go looking for instances of undefined behavior in a program with the goal of optimizing it in some way. There is little value in optimizing invalid code. The opposite is the case. Compilers do deliberately look to optimize loops with signed counters by exploiting UB to assume that they will never wrap.

I'd say both statements are correct. Compiler implementers are happy when they don't have to care about some edge case because then the code is simpler. Thus, only for unsigned counters there is the extra logic to compile them correctly. That is my interpretation of "The opposite is the case". Writing a compiler is easier with lots of undefined behavior.

But that's backwards, the compiler writers are writing special cases to erase checks in the signed case. Doing the 'dumb' thing and mindlessly going through the written check is simpler which is why that's what compilers did for decades as de facto standard on x86.

Re: Tell HN: C Experts Panel – Ask us anything about C

#782

Post by kazinator » Wed, Apr 15, 2020, 1:40 AM UTC

kevin_thibedeau wrote: post #779

saagarjha wrote: post #738

Earlier quoted context omitted.

Ok, but who actually uses that?

The point is to demonstrate that std::array isn't an array.

What makes you so sure that if C got better arrays, those would be arrays, supporting a[i] i[a] commutativity and all?

That is predicated on equivalence to *(a + i) where a is a dumb pointer whose displacement commutes.

Re: Tell HN: C Experts Panel – Ask us anything about C

#783

Post by saagarjha » Wed, Apr 15, 2020, 1:43 AM UTC

flatfinger wrote: post #758

DougGwyn wrote: post #144

Earlier quoted context omitted.

Actually there was no need to disenfranchise non-twos-complement architectures. Now that SIMH has a CDC-1700 emulation, I had planned on producing a C system for it as an example for students who have never seen such a model.

Rather than trying to decide whether to require that all implementations must use two's-complement math, or suggest that all programs should support unusual formats, the Standard should recognize some categories of implementations with various recommended traits, and programs that are portable among such implementations, but also recognize categories of "unusual" implementations. Recognizing common behavioral charact…

This sounds like something memcpy would do already for you?

Re: Tell HN: C Experts Panel – Ask us anything about C

#784

Post by vkou » Wed, Apr 15, 2020, 1:45 AM UTC

jschwartzi wrote: post #504

apotheon wrote: post #484

Earlier quoted context omitted.

This seems like a poor way to establish criteria for standardization. It essentially encourages non-standard practice and discourages portable code by saying that to improve the language standard we have to have mutually incompatible implementations. It has been said that design patterns (not just in the GOF sense of the term) are language design smells, implying that when very common patterns emerge it is a de facto…

What is your definition of "portable"? Are you using that term to mean "code I write for one platform can run without modification on other platforms" or "the language I use for one platform works on other platforms"? I think when you get down to the level of C you're looking at the latter much more than the former. C is really more of a platform-agnostic assembler. It's not a design smell to have conventions within…

> And the fact that length+pointer is such a common construct indicates that most people don't have any issues with it at all once they learn the language.

Given the prevalence of buffer overflow bugs in computing, I'd say that there are quite a few programmers who have quite a few issues with this concept in practice.

The rest of your arguments are quite sound, but I have to disagree with that one.

Re: Tell HN: C Experts Panel – Ask us anything about C

#785

Post by defectbydesign » Wed, Apr 15, 2020, 1:45 AM UTC

I am sorry to tell this but the C programming language doesn't need anymore the ISO committee since it introduced non de facto standard features such as VLA.

For reference I still use The C Programming Language by KERNIGHAN/RITCHIE and The Standard C Library by PLAUGER.

In my view what programmers need the most is good practices rather than any syntactic sugar.

I prefer C rather than any other programming language for its conciseness.

There is opportunities for any new programming language to replace C if it is at least backward compatible with K&R C SE (aka ISO C90) and provides a portable access to de facto standard hardware acceleration such as SIMD instructions for vector computing.

For now we have to write in assembly language SIMD optimized libraries in order to get the full calculation power of modern processors.

For programmers who expect C to bring them a hot drink, I would recommend them to stick with the bloated C++ framework which sometimes enlarges your p*s. :-P

Re: Tell HN: C Experts Panel – Ask us anything about C

#786

Post by saagarjha » Wed, Apr 15, 2020, 1:46 AM UTC

asveikau wrote: post #744

saagarjha wrote: post #728

Earlier quoted context omitted.

Misreads of much less than that have been exploitable in the past.

Depends a lot on the specifics. For example heartbleed was a misread that led to the buffer being sent on the socket. And I think it was more than 32 bits. 32 bits of garbage into a log file that needs privileges to read sounds a tad less scary, but like I say, not out of the question to be harmful.

32 bits is plenty to effectively break ASLR or significantly weaken a cryptographic key.

Re: Tell HN: C Experts Panel – Ask us anything about C

#787

Post by saagarjha » Wed, Apr 15, 2020, 1:47 AM UTC

flatfinger wrote: post #765

favorited wrote: post #719

Earlier quoted context omitted.

If most C developers wanted to trade the performance they get from the compiler being able to assume `n+1 > n` for signed integer n, it would happen.

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?

Re: Tell HN: C Experts Panel – Ask us anything about C

#788

Post by saagarjha » Wed, Apr 15, 2020, 1:51 AM UTC

SAI_Peregrinus wrote: post #760

spc476 wrote: post #701

Earlier quoted context omitted.

Well, that should be `snprintf()` to start with, but even with that, there are issues. The return type of `snprintf()` is `int`, so it can return a negative value if there was some error, so you have to check for that case. That out of the way, a positive return value is (and I'm quoting from the man page on my system) "[i]f the output was truncated due to this limit then the return value is the number of characters…

Not just embedded systems, also OSes. C's standard library should generally work without the existence of a heap. After all, you have to create the heap using C before you can allocate from it.

malloc is a required part of ISO C, though.

Re: Tell HN: C Experts Panel – Ask us anything about C

#789

Post by pvarangot » Wed, Apr 15, 2020, 1:54 AM UTC

JoeAltmaier wrote: post #630

napsy wrote: post #621

Earlier quoted context omitted.

An array is not a pointer. These are completely different data types. For example, you can't apply pointer arithmetic to arrays without casting them to pointers.

Sure you can. int aFoo[]; has many legal array operations possible: *(aFoo+3) should work fine and return the 4th int in the array.

I think your star operator there is making the compiler cast your array to pointer implicitly.

Re: Tell HN: C Experts Panel – Ask us anything about C

#790

Post by enhray » Wed, Apr 15, 2020, 1:55 AM UTC

pantalaimon wrote: post #23

Will C eventually get something like C++' constexpr?

Why do you want it in C? What are your use cases?

I’ve always thought that idiomatic C for constexpr would be to write the code you want to be executed at compile-time in a separate file(s), build it, execute and then #include the result in your program before building the final executable, adding a build step but keeping overall complexity minimal.

This is different from C++ approach, where everything and the kitchen sink is added to the standard and then you have to issue errata for errata for the standard and hope that the compiler you have to use for your current platform is keeping up for the last changes.