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

671–680 of 978 posts

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

#671

Post by quelsolaar »

DougGwyn wrote: post #649
quelsolaar wrote: post #619

Earlier quoted context omitted.

Modern assembly language has a huge set of instructions, that make them hard to learn, but the concept is still easy to learn.

Many antique computers are simulated by SIMH. If you have the corresponding software, you can operate on your desktop a simulated computer's software development system. For example, DEC VAX (VMS or Unix) has a relatively simple and sane assembly language.

I think, learning a tiny bit of assembler, even if in an emulator, is very valuable to teach the basics.

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

#672

Post by kzrdude »

klodolph wrote: post #387
kzrdude wrote: post #313

Earlier quoted context omitted.

Good point, but could it not be required that the unreachable code would be annotated to be unreachable? It could even have a (development only) assertion in the location.

That would be an immense undertaking. It’s not really just that some statement or expression is unreachable (we have __builtin_unreachable() in GCC for stuff like that) but that certain states are unreachable. For example, int buffer_len(struct buffer *buf) { return buf->end - buf->start; } There are at least three states that trigger undefined behavior: buf is not a valid pointer, buf->end - buf->start doesn’t fit i…

Thanks, so it's definitely easier said than done! Good explanation.

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

#673

Post by saagarjha »

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…

sizeof(ByteBuf) == sizeof(size_t), and you can pass it by value; I just don't think you can do anything useful with it because it'll chop off the data.

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

#674

Post by _kst_ »

DougGwyn wrote: post #572
hsivonen wrote: post #302

Does the committee have plans to deprecate (as in: give compiler license to complain suchthat compiler developers can appeal to yhe standard when users complain back) locale-sensitive functions like isdigit, which is useless for processing protocol syntax, because it is locale-sensitive, and useless for processing natural-language text, because it examines only one UTF-8 codw unit?

isdigit is likely to remain, because much existing code does use it (perhaps in different contexts from the one you cited). If you need a different function specification to do something different, it could be added in a future release, but that doesn't mean that we need to force programmers to change their existing code.

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 range of -128..+127. You might have a negative char value in a string -- but passing any negative value other than EOF to isdigit() has undefined behavior. Thus to use isdigit() safely on arbitrary data, you have to cast the argument to unsigned char:

    if (isdigit((unsigned char)s[i])) ...
A lot of C programmers aren't aware of this and will pass arbitrary char values to isdigit() and friends -- which works fine most of the time, but risks going kaboom.

Changing this could raise issues if -1 is a valid character value and also the value of EOF, but practically speaking -1 or 0xff will almost never be a digit in any real-world character set. (It's ÿ in Unicode and Latin-1, which might cause problems for islower and isalnum.)

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

#675

Post by saagarjha »

ATsch wrote: post #601
enriquto wrote: post #595

Earlier quoted context omitted.

That's a really bizarre layout for your struct. Why don't you put the length first?

I'm not sure if it matters. It might be better for some technical reason, such as speeding up double dereferences, because you don't need to add anything to get to the pointer. But to be honest I just copied it out of existing code.

Most platforms have instructions for dereferencing with a displacement.

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

#676

Post by pascal_cuoq »

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 (function that has no side-effects detected as pure, and call to that function omitted from a caller on this basis, when in fact the function may not terminate).

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

#677

Post by _kst_ »

shawnz wrote: post #85
stephencanon wrote: post #59

Earlier quoted context omitted.

> (because of e.g. casting to unsigned and allowing the same overflow to happen anyway) only work correctly on twos-complement anyway Unsigned arithmetic never overflows, and guarantees two's-complement behavior, because unsigned arithmetic is always carried out modulo 2^n: > A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer typ…

Wrapping around the modulus to me is an "overflow", although maybe the spec doesn't use the word that way

Right, there are (at least) two ways to describe this.

One is that unsigned arithmetic can overflow, and the behavior on overflow is defined to wrap around.

Another is to say that unsigned arithmetic cannot overflow because the result wraps around.

Both correctly describe the way it works; they just use the word "overflow" in different ways.

The C standard chooses the second way of describing it.

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

#678

Post by _kst_ »

stephencanon wrote: post #59
rbultje wrote: post #38

I'd love your opinion on the abundance of "undefined behaviour" (as opposed to implementation-defined, or some new incantation such as "unknown result in variable but system is safe") for relatively trivial things such as signed (but not unsigned) integer overflows. I've heard that this is to allow for non-twos-complement implementations. However, in practice, you notice that most people use ugly workarounds which le…

> (because of e.g. casting to unsigned and allowing the same overflow to happen anyway) only work correctly on twos-complement anyway Unsigned arithmetic never overflows, and guarantees two's-complement behavior, because unsigned arithmetic is always carried out modulo 2^n: > A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer typ…

A quibble on wording: Unsigned overflow is not "twos-complement". It gives you the same bit patterns that typical two's-complement overflow gives you, but strictly speaking two's-complement is a representation for signed values.

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

#679

Post by pdw »

uasm wrote: post #272
pascal_cuoq wrote: post #78

Earlier quoted context omitted.

I would recommend musl, although the style is a bit idiosyncratic in places: https://www.musl-libc.org Mbed TLS, since I have it in mind from another thread, is also a pretty clean C library for the problem it tries to solve; it's a testament to its design that we (TrustInSoft, who had not participated to its development) were able to verify that some uses of the library were free of Undefined Behavior: https://tls.m…

> "I would recommend musl, although the style is a bit idiosyncratic in places: https://www.musl-libc.org" Opened a random part of musl out of sheer boredom. Here's what I see: https://git.musl-libc.org/cgit/musl/tree/include/aio.h A bunch of return codes #defined like so (see https://git.musl-libc.org/cgit/musl/tree/src/aio/aio.c ): #define AIO_CANCELED 0 #define AIO_NOTCANCELED 1 #define AIO_ALLDONE 2 #define LIO_R…

musl is implementing POSIX. POSIX requires those constants to be preprocessor defines. (Generally, musl asssumes the reader is quite familiar with the C and POSIX standards, which makes sense since it's a libc implementation.)

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

#680

Post by DougGwyn »

begriffs wrote: post #667

Has there been a survey to determine what percentage of known compilers support each C version, like C89, C99, C11? I've been sticking to C99 because I assumed later versions won't be widely adopted for a long time to come. Is this accurate?

There is a Web page I saw a few days ago that does that, probably findable by grepping Wikipedia. Unfortunately I forget its URL.
Post reply on HN