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

821–830 of 978 posts

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

#821

Post by loeg »

_kst_ wrote: post #516
professoretc wrote: post #369

Earlier quoted context omitted.

The point of uintptr_t is that it's an integer type to which any pointer type can be cast. If you introduce a new class of pointers which are not compatible with uintptr_t, then suddenly you have pointers which are not pointers.

No, uintptr_t is an integer type to which any object pointer type can be converted without loss of information. (Strictly speaking, the guarantee is for conversion to and from void*.) And if an implementation doesn't have a sufficiently wide integer type, it won't define uintptr_t. (Likewise for intptr_t the signed equivalent.) There's no guarantee that a function pointer type can be converted to uintptr_t without lo…

Surely you're not arguing that a bounded array is in fact a function rather than an object? The distinction between function and object pointers exists for Harvard architecture computers, which sort of exist (old Atmel AVR before they adopted ARM), but are not dominant.

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

#822

Post by pjmlp »

nicoburns wrote: post #727
kazinator wrote: post #598

Earlier quoted context omitted.

> C++ introduces a shit-ton of stuff that one often doesn't want The point in my comment is that every single item in C++ was wanted and championed by someone , exactly like all the talk about adding this and that to C. > C shouldn't turn into C++ Well, C did turn into C++. The entity that gave forth C++ is C. Analogy: when we say "apes turned into humans", we don't mean that apes don't exist any more or are not cont…

Sure, but theres a vast space between the C and C++ approaches. You don't have to say yes to everything to say yes to a few things. I would suggest that better arrays are an example of something that pretty much everybody wants.

Apparently not everyone, otherwise it would be part of ISO C already, and it hasn't been for lack of trying.

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

#823

Post by pjmlp »

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.

That is a quirk of C's arrays, no other language besides Assembly allows for that.

And even in Assembly, it depends on the CPU flavor which kind of memory accesses are available.

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

#824

Post by pjmlp »

kazinator wrote: post #654
twic wrote: post #608

Earlier quoted context omitted.

> if you want a dialect of C with arrays that know their length, you can use C++ C++ doesn't have arrays which know their length.

C++ has features in its syntax so that you can write objects that behave like arrays: support [] indexing via operator [], and can be passed around (according to whatever ownershihp discipline you want: duplication, reference counting). C++ provides such objects in its standard library, such as: std::basic_string and std::vector . There is a newer std::array also.

And depending on the compiler they can also bounds check, even in release builds, it is a matter of enabling the right build configuration flags.

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

#825

Post by pjmlp »

adrianmonk wrote: post #506
tzs wrote: post #466

If an old timer who used to be good with C wanted to use C again, would they have to learn a whole bunch of weird new stuff or could they pretty much use it like they did back in the stone age (i.e., the 20th century)? Back in the '80s and '90s I was pretty good at C. I don't think there was anything about the language or the compilers than that I did not understand. I used C to write real time multitasking kernels f…

I'm sort of in the same boat, although I didn't do as much C. (And my interest in getting back into it is more hypothetical.) Aside from understanding how the language itself has changed, maybe something else to put on the list is how to apply more modern programming practices in C. In the 90s, I don't think I ever saw C code with unit tests. Any kind of automated testing was pretty rare. I've become convinced that t…

People did know about security back then, since it was one of the driving design factors of Burroughs created in 1961, and still sold by Unisys as ClearPath MCP for highly secured deployment environments.

And there were plenty of security related papers and OSes from other companies like IBM, Xerox and DEC.

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

#826

Post by clarry »

spc476 wrote: post #742
clarry wrote: post #684

Earlier quoted context omitted.

Huh? I just want performant code. That's why I write C, and that's why I use an optimizing compiler, and that's why I ask my compiler to optimize. I also want to write code that is reasonably generic. Thus, it will have checks and branches that cover important corner cases; they are required for completeness and correctness. But very often, all of these checks turn out to be redundant in a specific context, and an op…

Why can't the following be a warning? int foo(bar *x) { x->blah = 0; if (x == NULL) ... ... } And produce something like "NULL check removed---pointer used before check"?

In theory? No reason.

In practice it's a special case of a more widely applicable optimization where you actually do want to remove redundant checks. So someone has to go out of their way to figure out a rule that makes the compiler warn but only in cases where a human reader finds the optimization surprising and undesirable. It's a fuzzy thing and can easily lead to lots of false positives and noise (and more whining because it didn't warn in a situation that someone considered surprising).

I think that kind of logic can easily become a support & maintenance nightmare, so I'm not surprised that compiler developers take their time and are conservative when it comes to adding such things. I would probably just ask you to either stop dereferencing NULL pointers, or turn off the optimization if you want to dereference NULL pointers and eat your cake too.

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

#827

Post by lioeters »

Koshkin wrote: post #400

Why not keep C a simple little language with fast compile times and delegate all "enhancements" (such as 'cleanup') to C++?

From reading all their comments up to now, my feeling is that's exactly their plan.

When asked, "Where do you think C is going?", one of them said, "I don't see it going anywhere." I took that as a good thing, meaning, they're concerned about backward compatibility, compiler performance, and only adding features when there's a wide concensus in implementation - which is a high enough hurdle that avoids the feature bloat of C++.

Overall, I felt the "conservatism" refreshing, to keep the language small.

On the other hand, there are several common feature requests I see in this thread that probably will never be part of the language, since it moves slow relative to other languages.

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

#828

Post by a1369209993 »

ori_b wrote: post #368
DougGwyn wrote: post #191

Earlier quoted context omitted.

UTF-8 encoding works "as is" based on byte strings (char[]). The latest versions of the draft standard provide somewhat more support. I recommend heading toward a future where only UTF-8 encoding is used for multibyte characters and UCS-2 or similar for wchar_t. There is no need to support several different encodings.

UCS-2 is a bad choice -- it fails to represent most unicode characters. If you meant UTF-16, that's also a bad choice, because UTF-16 is also a variable width encoding, forcing programmers to use a some for of "extra-wide char". I'm of the opinion that wchar_t should become an alias for char32_t.

UTF-32 is also a variable-width encoding; eg 00000044 00000308 aka "D̈".

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

#829

Post by clarry »

flatfinger wrote: post #811
saagarjha wrote: post #787

Earlier quoted context omitted.

How is this better behavior?

Many programs are subject to two constraints: 1. Behave usefully when practical, if given valid data. 2. Do not behave intolerably, even when given maliciously crafted data. For a program to be considered usable, point #1 may be sometimes be negotiable (e.g. when given an input file which, while valid, is too big for the available memory). Point #2, however, should be considered non-negotiable. If integer calculation…

Intolerable is too situation specific.

Integer overflows that yield "weird values" in one place can easily lead to disasterous bugs in another place. So the safest thing in general would be to abort on integer overflow. But I'm sure there are applications where that, too, is intolerable. Kinda hard to have constraint 2 then.

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

#830

Post by lioeters »

Nemerie wrote: post #464
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…

There was a nice discussion recently https://news.ycombinator.com/item?id=22519876

I'm in a similar situation as the parent comment, wanting to re-learn C after more than a decade (or two). Thanks for the link to a recent discussion! For the parent, here are some of the recommended books:

Head First C - Griffiths and Griffiths

Expert C Programming: Deep C Secrets - Peter van der Linden

Modern C - Jens Gustedt

C Programming: A Modern Approach - K. N. King

21st Century C: C Tips from the New School - Ben Klemens

Understanding and Using C Pointers - Richard Reese

C Interfaces and Implementations: Techniques for Creating Reusable Software - David R. Hanson

The Standard C Library - P. J. Plauger

Post reply on HN