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

681–690 of 978 posts

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

#681

Post by kkdwivedi »

ATsch wrote: post #647
kkdwivedi wrote: post #620

Earlier quoted context omitted.

Another option is a struct with a FAM at the end. typedef struct { size_t len; uint8_t data[]; } ByteBuf; Then, allocation becomes ByteBuf *b = malloc(sizeof(*b) + sizeof(uint8_t) * array_size); b->len = array_size; and data is no longer a pointer.

Well, your ByteBuf is still a pointer. You also now need to dereference it to get the length. It also can't be passed by value, since it's very big. You can also not have multiple ByteBufs pointing at subsections of the same region of memory. Thing is, you rarely want to share just a buffer anyway. You probably have additional state, locks, etc. So what I do is embed my ByteBuf directly into another structure, which…

Right, totally depends on what you're doing. My example is not a good fit for intrusive use cases.

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

#682

Post by doublesCs »

pjscott wrote: post #596
doublesCs wrote: post #565

Earlier quoted context omitted.

What's wrong with: *p += sprintf(*p, "hello"); *p += sprintf(*p, "world");

That could lead to buffer overflow.����

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 case you couldn't tell.

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

#683

Post by rseacord »

_kst_ wrote: post #512
rseacord wrote: post #367

Earlier quoted context omitted.

I would say that there is a lot of concern in the committee about how compilers are optimizing based on pointer providence. There has been a study group looking at this. It now appears that they are likely to publish their proposal as a Technical Report.

"based on pointer providence" I think you meant "provenance" (mentioning it for the sake of anyone who wants to search for it).

Yes, my mistake--I was thinking of Rhode Island. I wrote a short bit about this at https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... if anyone is interested.

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

#684

Post by clarry »

quelsolaar wrote: post #666
clarry wrote: post #644

Earlier quoted context omitted.

I want my compiler to remove redundant checks (without any noise), and that is why I pass it an optimization flag. If you don't want such optimizations, then maybe you should not ask the compiler to make them.

This attitude is terrible! Its an attitude that says that unless you know exactly every pit fall in the language by heart you have no place writing code. I guess you dont use a debugger either because you never write bugs right? And you think that every software that helps the user is for noobs right? There is an endless list of bugs that have been produced by very competent C programmers, because the compiler has si…

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 optimizing compiler can figure it out, and eliminate these checks for me.

So I don't manually need to go and write two or three versions of each function like do_foo and assume_x_is_not_null_and_do_foo and assume_y_is_less_than_int_max_minus_sizeof_z_and_do_foo and make damn sure not to call the wrong one.

I just write one version, with the right checks in place, and if after macro expansion, inlining, range analysis, common subexpression elimination, and other inference from context, with C's semantics at hand, the compiler can figure out that some of these checks are redundant, then it will optimize them out.

I ask for it, and I'm glad compiler developers deliver it. You don't need to ask for it. Just turn off these optimizations (or, rather, don't enable them) if you prefer slow and redundant code.

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

#686

Post by wahern »

eqvinox wrote: post #102
ux wrote: post #66

Is there any plan to deal with the locale fiasco at some point? Some hints on what I'm referring to can be found here: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02... Unrelated, but I also miss a binary constant notation (such as 0b10101)

I haven't read most of that rant, but a thread-local setlocale() would be a godsend. Not sure if that's ISO C or POSIX though.

POSIX has added _l variants taking a locale_t argument to all the relevant string functions. I can see how per-thread state would be convenient, but it's not a comprehensive solution. With the _l variants you can write your own wrappers that pass a per-thread locale_t object.

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

#687

Post by temac »

pascal_cuoq wrote: post #676
eska wrote: post #653

There's a compiler attribute in GCC to promise that a function is pure, i.e. free from side effects and only uses its inputs. This is useful for parallel computations, optimizations and readability, e.g. sum += f(2); sum += f(2); can be optimized to x = f(2); sum += x; sum += x; Would the current motto of the consortium forbid adding a feature such as marking a function as pure, that would not just promise, but also…

If you wrote down your proposal, which the C committee member Robert Seacord is encouraging you to do here: https://news.ycombinator.com/item?id=22870210 , you would have to think carefully about functions that are pure according to your definition (free from side effects and only uses its inputs) but do not terminate for some inputs. There is at least one incorrect optimization present in Clang because of this (func…

I thought the compiler was free to pretend loops without side effects always terminate, and in that sense it is already a "correct" optimization? Or is it only for C++, I'm not sure?

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

#688

Post by pascal_cuoq »

cormacrelf wrote: post #515
pascal_cuoq wrote: post #479

Earlier quoted context omitted.

One concrete reason why “unspecified” means “anything and not always the same thing” is to enable the maximum of optimizations. Write a function c that compares pointers in a compilation unit, and in another compilation using, define: int a, b; X1 = (&a == &b + 1); X2 = c(&a, &b + 1); The compiler can optimize the computation of X1 on the basis that comparing an offset of &a to an offset of &b will always: - be false…

I get why unspecified means that and it’s good to know what the limit is for applying an optimisation, but I was asking about why the specific comparison of “one past the end” with the beginning of another being unspecified would be useful. It’s cool you can optimise it out, but what does a compiler gain from being able to do that? Imagine a standard stated that > and I guessed above that this is kinda like having ha…

Oh, that was your question. In this case, the reason why &a + 1 == &b is unspecified is that:

- it's generally false—there is no reason for b to be just after a in memory, so these two addresses compare different.

- it is sometimes true: when addresses are implemented as integers, and compilers use exactly sizeof(T) bytes to represent an object of type T, and do not waste precious integers by leaving gaps between objects, and == between pointers is implemented as the assembly instruction that compares integers, sometimes that instruction produces true for &a + 1 == &b, because b was placed just after a in memory.

In short, &a + 1 == &b was made unspecified so that compilers could implement pointer == by the integer equality instruction, and could place objects in memory without having to leave gaps between them. Anything more specific (such as “&a + 1 == &b is always false”) would have forced compilers to take additional measures against providing the wrong answer.

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

#689

Post by DougGwyn »

hsivonen wrote: post #333

What’s the current committee thinking on providing locale-independent conversions from potentially-invalid UTF-8 to valid UTF-8, from potentially-invalid UTF-8 to valid UTF-16, and from potentially-invalid UTF-16 to valid UTF-8 (i.e. replacing ill-formed sequences with yhe REPLACEMENT CHARACTER)?

If you changed UTF-16 to UTF-32 or UCS-4 I'd support it. I think there are already implementations that use the replacement character for all "impossible" codes.

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

#690

Post by xtian »

apotheon wrote: post #480
nabla9 wrote: post #450

Earlier quoted context omitted.

It was an observation, not suggestion. When the language standardization body has not managed to add arrays with length in 48 years, I don't think it should be added at this point. The culture is backward looking and incompatible with modern needs and people involved are old and incompatible with the future (no offense, so am I). C standardization effort should focus on finishing the language, not developing it to ma…

> If I would propose new extension to C language, I would propose completely new language that can be optionally compiled into C and works side by side with old C code. There are a few somewhat popular languages that fit that description already, and none of them are suitable replacements for C (as far as I've seen). That's not to say there couldn't be a suitable replacement -- just that nobody in a position to do so…

Sounds like you are describing Zig. https://ziglang.org
Post reply on HN