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

461–470 of 978 posts

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

#461

Post by azinman2 »

pascal_cuoq wrote: post #454
commandersaki wrote: post #436

A few years ago I came across this article Pointers Are More Abstract Than You Might Expect In C [1]. I followed the article which attempted to interpret the C standard and come to a conclusion. The conclusion is: > The takeaway message is that pointer arithmetic is only defined for pointers pointing into array objects or one past the last element. Comparing pointers for equality is defined if both pointers are deriv…

The only thing that is not defined is comparing a pointer one-past-the-end to a pointer to the very beginning of a toplevel object. Apart from this rule, pointers of course do not need to be derived from the same object in order to be compared with == and !=. &a + 1 == &b is unspecified: it may produce 0 or 1, and it may not produce the same result if you evaluate it several times. Similarly, if both the char pointer…

Why is this undefined if it’s all just pointers to addresses in memory, regardless if the memory is valid for that object or not?

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

#463

Post by jcelerier »

AaronBallman wrote: post #331
lemaudit wrote: post #238

Hi, Do you think Annex K of C11 will be widely adopted by programmers or unused? Why aren't people adopting it? Do you see the use of any analysis tools that are particularly effective for finding memory safety issues? C++ added in smart pointers to its specification. Are there any plans to do something similar in future C specifications? Thanks!

> Do you think Annex K of C11 will be widely adopted by programmers or unused? Why aren't people adopting it? So far, it's not been widely adopted. Part of the issue is that there are specification issues relating to threads and the constraint handlers, and part of the issue is that popular libc implementations have actively resisted implementing the annex. That said, I field questions about Annex K on a regular basi…

> We currently don't have any proposals for adding smart pointers to C. Given that C does not have constructors or destructors, we would have to devise some new mechanism to implement or replace RAII in C, which would be one major hurdle to overcome for smart pointers.

why would you have to devise a new mechanism and not borrow one from one of the thousand other mechanisms already existing in PL litterature for this ?

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

#464

Post by Nemerie »

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

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

#465

Post by moonchild »

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?

Converting arrays of utf8-encoded char to arrays of utf32-encoded 'rune' would probably not do what you want. That still leaves e.g. combining diacritical marks as separate from the characters they modify. If you care about breaking up text into codepoints, you probably also care about that sort of thing. The base unit of unicode is the extended grapheme cluster. In order to actually convert text into extended grapheme clusters, however, you need to have a database that tells you what kind of codepoint each codepoint is. Since c is standardized less frequently than unicode, any kind of unicode or utf support from the specification would quickly get out of date.

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

#466

Post by tzs »

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 for embedded systems, device drivers and kernel extensions for Unix, Windows, Mac, Netware, and OS/2. I did a Unix port from swapping hardware to paging hardware, rewriting the processes and memory subsystems. I tricked a friend into writing a C compiler. I could hold my own with the language lawyers on comp.lang.c.

Somewhere in there I started using C++, but only as a C with more flexible strings, constructors, destructors, and "for (int i = ...)", and later added STL containers to that.

Sometime in the 2000s, I ended up spending more and more time on smaller programs that were mostly processing text, and Perl became my main tool. Also I ended up spending a lot of helping out less experiences people at work who were doing things in PHP, or JavaScript, or Java. My C and C++ trickled to nothing.

I've occasionally looked at modern C++, but it is so different from what I was doing back in '90s or even early '00s I sometimes have to double check that I'm actually looking at C++ code.

Is modern C like that, or is it still at its core the same language I used to know well?

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

#467

Post by cormacrelf »

pascal_cuoq wrote: post #454
commandersaki wrote: post #436

A few years ago I came across this article Pointers Are More Abstract Than You Might Expect In C [1]. I followed the article which attempted to interpret the C standard and come to a conclusion. The conclusion is: > The takeaway message is that pointer arithmetic is only defined for pointers pointing into array objects or one past the last element. Comparing pointers for equality is defined if both pointers are deriv…

The only thing that is not defined is comparing a pointer one-past-the-end to a pointer to the very beginning of a toplevel object. Apart from this rule, pointers of course do not need to be derived from the same object in order to be compared with == and !=. &a + 1 == &b is unspecified: it may produce 0 or 1, and it may not produce the same result if you evaluate it several times. Similarly, if both the char pointer…

That’s quite precise, can you give a sense of why it’s useful to have? Does it translate as “you can never know whether two mallocs are adjacent, so don’t even try merging them”?

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

#468

Post by msebor »

Daemon404 wrote: post #58

What has been the rationale or hinderance for not adding locale-independent versions of various stdlib functions? Practically every second C codebase on earth has their own implementations of these at some point, and it remains a huge problem for e.g. writers of libraries, where you don't know how/where your library will be used.

First, there needs to be a proposal for adding a feature (I'm not aware of one having been submitted recently). Second, any non-trivial proposed feature needs to have some existing user experience behind it. For libraries that typically means implementations shipping with operating systems or compilers (but successful third party libraries might also be considered). Finally, it also needs to appeal to people on the committee; that can be quite challenging as well. Many proposals that meet the first two criteria die because they simply don't get enough support within the committee.

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

#469

Post by grok22 »

Things I would like C to have:

- stricter type-checks on typedef types (useful when passing function parameters) - gcc's ' warn_unused_result' attribute for functions (ensure error returns are checked) - on-entry/on-exit qualifiers for functions (to do things like make sure you lock/unlock semaphores for instance before entry/exit of function) - D language's 'scope' feature (better handling of error path) - loops in the c pre-processor! (better code-gen)

Any chance any of this is on the radar for the next-gen C standard? Some of these are just ergonomics, but the first two might've have saved me some grief a few times.

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

#470

Post by pascal_cuoq »

haberman wrote: post #406
pascal_cuoq wrote: post #266

Earlier quoted context omitted.

Yes and no. The thing I am describing is when you link a compilation unit using: struct internal_state { int dummy; } state; with another compilation unit that defined the same state differently: struct internal_state { int actual_meaningful_member_1; unsigned long actual_meaningful_member_2; } state; As far as I know, BSD socked do not do this. Zlib was doing this ( https://github.com/pascal-cuoq/zlib-fork/blob/a52f…

I'm curious what exactly makes this undefined behavior. And in particular, what about something like this? struct Foo { #ifdef __cplusplus int bar() const { return bar_; } private: #endif int bar_; }; Or, taking this a step further: struct _Foo; typedef struct _Foo Foo; // In C "struct _Foo" is never defined. int Foo_bar(const Foo* foo) { return *(int*)foo; } void Foo_setbar(Foo* foo) { *(int*)foo; } Foo* Foo_new() {…

I think this is plenty ok. For one thing, If a struct as a member of type T, it's ok to access it through a pointer to T (and also the address of the struct is guaranteed to be identical to the address of the first member). For another, you are using dynamically allocated memory, so the only thing that matters is the type of the pointer when the access is finally made. It doesn't matter that it was a Foo* before, if what you dereference is an int*.

This is different from pretending that the address of a struct s { int a; double b; } is the address of a struct t { int a; long long c; } and accessing it through a pointer to that. If you do that, C compilers will (given the opportunity) assume that the write-through-a-pointer-to-struct-t does not modify any object of type “struct s”. This is what the example st1 in the article illustrates.

The latter is what I suspect plenty of socket implementations still do (because there are several types of sockets, represented by different struct types with a common prefix). It is possible to revise them carefully so that they do not break the rules, but I doubt this work has been done.

Post reply on HN