Tell HN: C Experts Panel – Ask us anything about C • Hacker News Board

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

#931

Post by apotheon » Thu, Apr 16, 2020, 5:23 PM UTC

xtian wrote: post #690

apotheon wrote: post #480

Earlier quoted context omitted.

> 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

I haven't looked at Zig too closely yet (only started just a few minutes ago), but it immediately appears to me that this violates one of the requirements I suggested, as demonstrated by this use-case wish from my previous comment:

> > using the new language's compiler as the project compiler front end's drop-in replacement (without having to make any changes to the code at all for this first step)

I'll look into Zig more, though. Maybe I'll like it.

---

I stand corrected, given my phrasing. I should have specified that it needs to also support incrementally adding the new language's features while most of the code is still unaltered C, rather than (for instance) having to suddenly replace all the includes and function prototypes just because you want to add (in the case of Zig) an error "catch" clause.

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

#932

Post by flatfinger » Thu, Apr 16, 2020, 7:36 PM UTC

mpweiher wrote: post #925

flatfinger wrote: post #901

Earlier quoted context omitted.

> It should be obvious to compiler writers what the intention of the standard is, because it says so in the dang text, but since this was downgraded to a note and you are technically not in violation if you do something different, everyone now acts as if doing the exact opposite of what is written there is somehow OK. Note that a compiler could be incapable of processing any useful programs whatsoever, and yet still…

Yep, that is exactly my analysis of the situation: an actual compiler vendor would never ( could never) pull any of these stunts, or they'd simply go out of business in a jiffy. Alas, we all got suckered into "free", and now the compiler writers no longer listen to their users, because they are not their customers. Their customers are they PhD advisers and Google, Apple and maybe a few more "whales" as Stonebraker de…

BTW, what do you think of the suggested text I offered near the top of this thread, that UB represents a waiver of the Standard's jurisdiction for the purpose of allowing implementations to best serve their intended purposes? It's too late to go back in time and add that to C89 or C99, but a lot of insanity could have been avoided had such text been present.

Further, instead of characterizing as UB all situations where a useful optimization might affect the behavior of a program, it would be far much safer and more useful to allow particular optimizations in cases where their effects might be observable, but where all allowable resulting behaviors would meet application requirements.

As a simple example, instead of saying "a compiler may assume that all loops with non-constant conditions will terminate", I would say that if the exit of a loop is reachable, and no individual action within the loop would be observably sequenced with regard to some particular succeeding operation, a compiler may at its leisure reorder the succeeding operation ahead of the loop. Additionally, if code gets stuck in a loop with no side effects that will never terminate, an implementation may provide an option to raise a signal to indicate that.

If a function is supposed to return a value meeting some criterion, and it would find such a value in all cases where a program could execute usefully, but the program would do something much worse than useless if the function were to return a value not meeting the criteria, a program execution where the function loops forever may be useless, and may be inferior to one that gets abnormally terminated by the aforementioned signal, but may be infinitely preferable to one where the function, as a result of "optimization", returns a bogus value. Allowing a programmer to safely write a loop which might end up not terminating would make it possible to yield more efficient machine code than would be needed if the only way to prevent the function from returning a bogus value would be to include optimizer-proof code to guard against the endless-loop case.

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

#933

Post by flatfinger » Thu, Apr 16, 2020, 8:45 PM UTC

apotheon wrote: post #929

cperciva wrote: post #520

Earlier quoted context omitted.

One of the principles for the C language is that you should be able to use C on pretty much any platform out there. This is one of the reasons that other languages are often written in C. In order to uphold that principle, it's important that the standard consider not just "is this useful" but "is this going to be reasonably straightforward for compiler authors to add". Seeing that people have already implemented a f…

That's obviously true, but at the same time the specifics of how one chooses to set criteria for inclusion in the standard should probably keep in mind the social consequences. If the intended consequence (e.g. ensuring that implementation is easy enough and desired enough to end up broadly included for portability) and the likely consequence (e.g. reduced standardization of C capabilities in practice, with rampant r…

What is meant by "portable code"? Should it refer only to code that should theoretically be usable on all imaginable implementations, or should it be expanded to include code which may not be accepted by all implementations, but which would have an unambiguous meaning on all implementations that accept it?

Historically, if there was some action or construct that different implementations would process in different ways that were well suited to their target platforms and purposes, but were incompatible with each other, the Standard would simply regard such an action as invoking Undefined Behavior, so as to avoid requiring that any implementations change in a way that would break existing code. This worked fine in an era where people were used to examining upon precedent to know how implementations intended for certain kinds of platforms and purposes should be expected to process certain constructs. Such an approach is becoming increasingly untenable, however.

If instead the Standard were to specify directives and say that if a program starts with directive X, implementations may either process integer overflow with precise wrapping semantics or refuse to process it altogether, if it starts with directive Y, implementations may either process it treating "long" as a 32-bit type or refuse to process it altogether, etc. this would make it much more practical to write portable programs. Not all programs would run on all implementations, but if many users of an implementation that targets a 64-bit platform need to use code that was designed around traditional microcomputer integer types, a directive demanding that "long" be 32 bits would provide a clear path for the implementation to meet its customers' needs.

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

#934

Post by flatfinger » Thu, Apr 16, 2020, 8:50 PM UTC

a1369209993 wrote: post #914

flatfinger wrote: post #906

Earlier quoted context omitted.

> Although I do disagree that writing a signed value is useful Although the Standard defines the behavior of signed-to-unsigned conversion in a way that would yield the same bit pattern as a two's-complement signed number, some compilers will issue warnings if a signed value is implicitly coerced to unsigned. Adding the extra 18 forms would generally require nothing more than defining an extra 24 macros, which seems…

Fair point; even if the combinatorical nature of it is superficially alarming, that's probably not a productive area to worry about feature creep in.

72 static in-line functions. If a compiler does a good job of handling such things efficiently, most of them could be accommodated by chaining to another function once or twice (e.g. to read a 64-bit value that's known to be at least 16-bit aligned, on a platform that doesn't support unaligned reads, read and combine two 32-bit values that are known to be 16-bit likewise).

Far less bloat than would be needed for a compiler to recognize and optimize any meaningful fraction of the ways people might write code to work around the lack of portably-specified library functions.

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

#935

Post by flatfinger » Thu, Apr 16, 2020, 8:56 PM UTC

thayne wrote: post #917

flatfinger wrote: post #835

Earlier quoted context omitted.

The semantics most programs need for overflow are to ensure that (1) overflow does not have intolerable side effects beyond yielding a likely-meaningless value, and (2) some programs may need to know whether an overflow might have produced an observably-arithmetically-incorrect result. A smart compiler for a well-designed language should in many cases be able to meet these requirements much more efficiently than it c…

oops, i meant the wrapping_* functions

If one wants a function that will compute xy/z when xy doesn't overflow, and yield some arbitrary value (but without other side-effects) when it does, wrapping functions will often be much slower than would be code that doesn't have to guarantee any particular value in case of overflow. If e.g. y is known to be 30 and z equal to 15, code using a wrapping multiply would need to be processed by multiplying the value by 30, computing a truncated the result, and dividing that by 15. If the program could use loosely-defined multiplication and division operators, however, the expression could be simplified to x+x.

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

#936

Post by flatfinger » Thu, Apr 16, 2020, 8:59 PM UTC

JoeAltmaier wrote: post #918

GTP wrote: post #884

Earlier quoted context omitted.

This isn't a good idea either: if you're dealing with undefined behavior the way the complier translates your code can change from version to version, so you could end up with a code that works with the current version of GCC but doesn't work on the next. Personally I don't agree with the way GCC and other comipers deal with UB, but this would be off topic.

Hm. May be off-topic by now. Incrementing an int is going to work the same on the same hardware, forever. Nothing the compile has any say in.

If a compiler decides that it's going to process:

    unsigned mul(unsigned short x, unsigned short y)
    { return x*y; }

in a way that causes calling code to behave in meaningless fashion if x would exceed INT_MAX/y [something gcc will sometimes actually do, by the way, with that exact function!], the hardware isn't going to have any say in that.

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

#937

Post by flatfinger » Thu, Apr 16, 2020, 9:03 PM UTC

aw1621107 wrote: post #915

graycat wrote: post #545

Earlier quoted context omitted.

Thanks. > Did you have more specific questions in mind? On stack overflow, my understanding was that could encounter that fatal condition from suddenly a too deep call stack , that is, too many calls without a return. So, if the "stack" is a, say, finite resource, then the programmer should know in the code how much of that resource is being used and act accordingly. For a preprocessor for C++, I IIRC at one point th…

> So, if the "stack" is a, say, finite resource, then the programmer should know in the code how much of that resource is being used and act accordingly. And this is true, but IIRC statically determining stack bounds for arbitrary programs is not an easy problem to solve, especially if you call into opaque third-party libraries. > For a preprocessor for C++, I IIRC at one point the definition of C++ was in terms of a…

If the Standard were to make recursion an optional feature, many programs' stack usage could be statically verified. Indeed, there are some not-quite-conforming compilers which can statically verify stack usage--a feature which for many purposes would be far more useful than support for recursion.

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

#938

Post by flatfinger » Thu, Apr 16, 2020, 9:08 PM UTC

radford-neal wrote: post #544

emilfihlman wrote: post #344

Earlier quoted context omitted.

At least from what I've heard that's because stdint values are optional. 6.2.5p17 The three types char, signed char, and unsigned char are collectively called the character types. The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char. 48) and 5.2.4.2.1 says that width of char, signed char and unsigned char are the same (8).

I don't think it's anything to do with uint8_t being optional. It's because a char might have more than 8 bits.

A conforming implementation could extend the language with an 8-bit type __nonaliasingbyte which has no special aliasing privileges, and define uint8_t as being synonymous with that type.

On the other hand, the Standard should never have given character types special aliasing rules to begin with. Such rules would have been unnecessary if the Standard had noted that an access to an lvalue which is freshly visibly derived from another is an access to the lvalue from which it is derived. The question of whether a compiler recognizes a particular lvalue as "freshly visibly derived" from another is a Quality of Implementation issue outside the Standard's jurisdiction.

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

#939

Post by zoomablemind » Thu, Apr 16, 2020, 9:33 PM UTC

benibela wrote: post #892

gkfasdfasdf wrote: post #879

Earlier quoted context omitted.

What are the advantages of saving the end as a pointer? Genuinely curious. Seems like a length allows the end pointer to be quickly calculated (data + len), while being more useful for comparisons, etc.

You can remove the first k elements of a view with data += k. With the length you would need to do data += k; length -= k Especially if you want to use it as safe iterator, you can do data++ in a loop

> ...You can remove the first k elements of a view with data += k.

How would you safely free(data) afterwards? You'd need to keep an alloc'ed pointer somehow.

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

#940

Post by xtian » Thu, Apr 16, 2020, 9:55 PM UTC

apotheon wrote: post #931

xtian wrote: post #690

Earlier quoted context omitted.

Sounds like you are describing Zig. https://ziglang.org

I haven't looked at Zig too closely yet (only started just a few minutes ago), but it immediately appears to me that this violates one of the requirements I suggested, as demonstrated by this use-case wish from my previous comment: > > using the new language's compiler as the project compiler front end's drop-in replacement (without having to make any changes to the code at all for this first step) I'll look into Zig…

You can use the Zig compiler to compile C with no modifications, and easily call C from Zig or Zig from C, so I'm not sure what more you're hoping for. A language that allows you to mix standard C and "improved C" in the same file sounds like a mess to me.