Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

731–740 of 978 posts

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

#731

Post by _kst_ »

enriquto wrote: post #613
_kst_ wrote: post #526

Earlier quoted context omitted.

> Now that C2x plans to make two's complement the only sign representation, is there any reason why signed overflow has to continue being undefined behavior? I presume you'd want signed overflow to have the usual 2's-complement wraparound behavior. One problem with that is that a compiler (probably) couldn't warn about overflows that are actually errors. For example: int n = INT_MAX; /* ... */ n++; With integer overf…

> In the code above, is there any sense in which INT_MIN is the "right" answer for any typical problem domain? There is no answer different that INT_MIN that would be right and make sense, i.e. the natural properties of the + operator (associativity, commutativity) are respected. Thus, by want of another possibility, INT_MIN is precisely the right answer to your code. I read your code and it seems to me very clear th…

> I read your code and it seems to me very clear that INT_MIN is exactly what the programmer intended.

Well, I'm the author and that's not what I intended.

I used INT_MAX as the initial value because it was a simple example. Imagine a case where the value happens to be equal to INT_MAX, and then you add 1 to it.

The fact that no result other than INT_MIN makes sense doesn't imply that INT_MIN does make sense. Saturation (having INT_MAX + 1 yield INT_MAX) or reporting an error seem equally sensible. We don't know which behavior is "correct" without knowing anything about the problem domain and what the program is supposed to do.

A likely scenario is that the programmer didn't intend the computation to overflow at all, but the program encountered input that the programmer hadn't anticipated.

INT_MAX + 1 commonly yields INT_MIN because typical hardware happens to work that way. It's not particularly meaningful in mathematical terms.

As for "natural properties", it violates "n + 1 > n". C integers are not, and cannot be, mathematical integers (unless you can restrict values to the range they support).

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

#732

Post by emmelaich »

baybal2 wrote: post #140

Hello, I coded in C as a high schooler. Now, 16 years later, I have to code C again semiprofessionally after a very long break. Big question, how to start programming in C on a high professional level for somebody self schooled in it? Is there a way to cut the corner, without having to go through 10+ years trial and error to gain experience? Anything for somebody ready to sit, study, and practice for a few hours a da…

Compilers are much more helpful now. Better diagnostics, more options for warnings.

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

#733

Post by _kst_ »

emmelaich wrote: post #722
_kst_ wrote: post #674

Earlier quoted context omitted.

What about giving isdigit and friends defined behavior for any argument value that's within the range of any of char, signed char, or unsigned char? The background (I know Doug knows this): isdigit() takes an argument of type int, which is required to be either within the range of unsigned char, or have the value EOF (required to be negative, typically -1). The problem: plain char is often signed, typically with a ra…

I remember that the various is* man pages noted that most of them are only defined if isascii() is true. So I always used e.g. (isascii(x) && ispunct()) FWIW, just looked at the man page (macos) and iswdigit() and isnumber() are mentioned.

isascii() is not defined by ISO C. (It is defined by POSIX, but POSIX says it may be removed in a future version.)

I see that POSIX explicitly says that isascii(x) is "defined on all integer values" (it should have said "all int values").

Personally I'd rather cast to unsigned char.

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

#734

Post by blocks_plz »

AaronBallman wrote: post #659
blocks_plz wrote: post #261

Thanks for the AMA 1. Will the Apple's Blocks extension, which allows creation of Closures and Lambda functions, be included in C2X? 2. Are there any plans to improve the _Generic interface (to make it easy to switch on multiple arguements, etc.)?

> 1. Will the Apple's Blocks extension, which allows creation of Closures and Lambda functions, be included in C2X? We haven't seen a proposal to add them to C2x, yet. However, there has been some interest within the committee regarding the idea, so I think such a proposal could have some support. > 2. Are there any plans to improve the _Generic interface (to make it easy to switch on multiple arguements, etc.)? I ha…

1. The reason I asked was because I remember reading the proposal as N2030[1] and N1451[2] a while back. Were these never actually presented for voting? (not sure how the commitee works)

[1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2030.pdf

[2]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1451.pdf

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

#735

Post by saagarjha »

ori_b wrote: post #398
msebor wrote: post #370

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. But we must write code that relies on the same rules and requirements that programs are held to (and vice versa). When either party breaks those…

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.

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

#738

Post by saagarjha »

kevin_thibedeau wrote: post #704
zokier wrote: post #650

Earlier quoted context omitted.

What's std::array then? > combines the performance and accessibility of a C-style array with the benefits of a standard container, such as knowing its own size https://en.cppreference.com/w/cpp/container/array

They're objects that mostly behave like arrays. You can't index element two of std::array foo as 1[foo] since it isn't an actual C array.

Ok, but who actually uses that?

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

#739

Post by fanf2 »

beefhash wrote: post #55

C has been making strides towards complete Unicode support. I've been having trouble following along though: Am I correct in assuming that there's no actual multi-byte UTF-8 to UTF-32 Rune function and the best approximation depends on whatever wchar_t is? How would I best handle pure Unicode input and output scenarios on a "hostile" OS whose native character encoding is some EBCDIC abomination or a Windows codepage?

Are you looking for mbstowcs() or mbtowc() ?

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

#740

Post by userbinator »

Spivak wrote: post #578
msebor wrote: post #397

Earlier quoted context omitted.

This is a good example. Let me flesh it out a bit more to illustrate a specific instance of this problem: int a[2][2]; int f (int i, int j) { int t = a[1][j]; a[0][i] = 0; // cannot change a[1] return a[1][j] - t; // can be folded to zero } The language says that elements of the matrix a must only be accessed by indices that are valid for each bound, so compilers can and some do optimize code based on that requiremen…

But I don't know what you want to happen in this case? If you actually call f(2,0) then the program makes no sense. How can you have an expected value for a function call that violates its preconditions?

Based on the memory layout of arrays, which AFAIK is defined rather strictly by the standard, a[0][2] will be the same as a[1][0].
Post reply on HN