Hacker News Reader

> Does anyone have some better ideas?

gcc's C extensions have some good ideas [1], particularly:

1. typeof(e) operator: great for use in macros

2. labels as values: used in just about every language interpeter

3. statement expressions: great for use in macros

4. fixed point types: who wants to hack their own fixed precision arithmetic?

5. vector extensions

6. arithmetic functions with overflow checking

I think all of the above would make good additions to the C standard.

[1] https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html

Well said.

I'd like to see the gcc ".." operator for range-based switch cases and designated initializers become standardized.

As long as we keep __builtin_apply out of the standard, GCC is loaded with good ideas.

Yeah, after reading that I was really wondering about the use case for those extensions at the time they were added. I honestly can't think of any now.

I'm not liking the fixed-point types.

I'd rather see the ability to place an attribute on a floating-point variable that would inform the compiler that fixed-point might be suitable. You'd specify the requirements that need to be met, and the compiler would choose the fastest format for the current architecture. That format could be fixed-point, decimal float, IEEE float, or something weirder.

For example, your requirements could include: minimum magnitude, maximum magnitude, minimum value, maximum value, maximum additive error, maximum multiplicative error, signed zero needed or not, NaN signed/unsupported/unsigned, infinity distinct from NaN and/or the largest number, etc.

You say what you need for correctness, and the compiler makes it happen.

Fixed-point and floating-point types have very different behavior. I can't think of a case where I'd want to let the compiler decide which one to use.

No, normally what people desire of a fixed-point representation is a subset of a floating-point representation. Most fixed-point stuff is prototyped as floating-point, then painfully converted into a mess of nasty macros. Ideally there would be assertions to protect against failure due to the limited functionality of the fixed-point type, but probably you don't bother.

It's not maintainable.

We should be able to take that prototype, mark it up with hints for the compiler, and then build with fixed-point enabled.

TR 18037¹ defines fixed point arithmetic, but it does not seem well supported.

¹ http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1169.pdf

As far as I can tell, a programmer can't specify the number of fractional bits. The type "unsigned short _Fract", for example, has a number of fraction bits determined by the implementation within limits imposed by the standard. There's no way to ask for a type with, for example, 12 integral bits and 4 fractional bits.

Do hardware constraints make, for example, an 8.8 bit format easier to handle than a 12.4 format?

Compare Ada's fixed-point types, which let you specify the range and delta:

    type Fixed is delta 0.0625 range 0.0 .. 4095.9375;

> Do hardware constraints make, for example, an 8.8 bit format easier to handle than a 12.4 format?

Sometimes they do. For example, the ARMv7 DSP extensions support signed Q0.31 and signed Q0.15 arithmetic much faster than any other fixed-point format.

In these cases, I usually use while(true) with break, like

  while (true) {
    const bool flag = do_something();
    if (!flag) break;
  }

I'm curious if your version is exactly equivalent to the OP's, or is there something not covered here?

It does what the parent wanted. Just not as concise. do-while isn't all that common anyway.

My would-like-to-have in C is some equivalent of D's *Scope Guard" statement (https://dlang.org/spec/statement.html#ScopeGuardStatement) -- this will make error handling so much cleaner.

It seems the consensus is that new features like "auto" are not wanted:

Principle 13: Unlike for C99, the consensus at the London meeting was that there should be no invention, without exception. Only those features that have a history and are in common use by a commercial implementation should be considered

Bummer. Oh well, at least typeof and compound expressions can be blessed?

Do you really consider it an invention? I think they mean inventions done by the committee (like <locale.h>). ISO C++ has this feature. And so does GNU C via the __auto_type keyword (GCC 4.9 and clang 3.8). History is there but I doubt it's commonly used (in C yet).

Well, does implementation in C++ count? The wording is ambiguous.

This means that you should convince a compiler maker to add your innovation as a C extension. When it has been tested that way for a while, it may be added to the standard.

If you're using GNU C:

    #define AUTO(var, def) __typeof__(def) var = (def)

    AUTO(x, 3);

Or, as of GCC 4.9 and Clang 3.8, just use __auto_type. It avoids duplicating the source expression, which duplicates compiler errors if the expression is erroneous and can actually repeat side effects in the rare cases involving variable-length arrays.

Things I'd like to see

static lifetime compound literals. I don't see any reason not to be able to get the same effect as string literals for other types like:

return (static int const []){1, 2, 3};

Disallowing branch-predicted values for relaxed atomic operations. I think c++ did this and it seems the sane way to go.

Binary literals and binary printf format specifier. It would just occasionally be nice compared to hex.

countof macro for arrays. I don't even care if it checked for non-array type errors, it would just be nice for it to be standard.

Statement expressions and function literals would be nice, but I don't feel strongly about it.

Auto's a great thought. It would really kill a class of numerical operations that lead to overflow with type mixing. On the other hand, I once had to get to terms with a code base with the most generous amount of autos. The class hierarchy was maybe was maybe 20 levels with an adequate amount of branching. At any point, I had no idea what particular object I was dealing with and always had to go follow a labyrinthine chain of predecessor function calls to determine the object type actually assigned to an object.

On auto. Couldn't they just define auto as

  _Auto

and then add a header like <stdauto.h> which does

  #define auto _Auto

like they did with _Bool in C99?

auto is already a keyword in C11, a type of storage specifier (like static or register).

Yes, that's exactly why they'd use _Auto and a header to redefine the keyword. Existing code that does auto x = 3; (implicit int type) wouldn't break, but #include <stdauto.h> auto x = 4.2f; would be the new meaning.

Existing code that does "auto x = 3;" is already broken; the "implicit int" rule was removed in C99.

But "auto int x = 3;" is valid (and the "auto" keyword is useless in that context).

From <http://www.seebs.net/faqs/c-iaq.html#section-1>:

1.8: What's the auto keyword good for?

Declaring vehicles.

This is inherited from early Lisp implementations, where it was common to define a

  struct car { ... };

which would get cumbersome to type.

Super against auto. The type is implicit documemtation, and auto hides that. It probably also increases compile times.

It doesn't increase compile times. The type information is already there for type checking.

For your first case, why not:

  do {
  } while(!do_something());

Not trying to be snarky, I'd just like to understand :)

Because it's often either like this:

    do {
      const bool flag = do_something();
      do_something_else();
    } while(!flag);

Or like this:

    do {
      int whatever = get_some_data();
      const bool flag = do_something(whatever);
    } while(!flag);

Someone mentioned this instead:

  while (true) {
    const bool flag = do_something();
    if (!flag) break;
  }

Is it not what grandparent wanted?

Yes, that would do it. It would just be nice to have it be better supported in the language rather than working around it like this. Any time you introduce break or continue into a loop you're making it more difficult to follow what's going on, since suddenly the exit condition can be anywhere. Not a big deal, especially if there's only one and it's right at the end, but mildly annoying that it can't be expressed more naturally.

I've only somewhat recently become a hardcore C programmer, but I actually quite like it. Wrote my own incremental generational garbage collector recently—the things you can do in C are fun. Here are some things I'd really like:

Not language, rather standard library, but I would like to see a new allocation API with explicit control over alignment, separation of reserving and committing addresses, and generally updated for the fact that memory systems are different now than they were in 1979.

aligned_alloc is alright, except there's no aligned_realloc. Linux always reserves addresses and doesn't commit until it needs to, but that can't be relied on for portable code.

In short: we're in a 64-bit, virtual memory world. I don't want an allocator design from 1979.

It's about time glibc's custom streams[1] get standardized. Real talk, it's 2016 and we can't define custom FILE * types. This doesn't even need to expose the libc's FILE implementation; it can remain opaque just fine.

Language-wise, I'd like to see a pragma to covert an array of structs to a struct of arrays; i.e. declare

  #pragma struct SOA
  struct entity {
    uint32_t id;
    ...
  };

  struct entity all_entities[1000];

and have the compiler rewrite it to

  struct {
    uint32_t id[1000];
    ...[1000];
  } all_entities;  // where typeof(all_entites[N]) == typeof(struct entity)

à la Jai[2]. This isn't a particularly hard transformation to do by hand, but it's kind of tedious.

Standardizing M4 as a preprocessor would be a nice-to-have; i.e. you should be able to compile a .h.m4 or .c.m4 file directly. I don't know why GCC can't do this yet. It's a bit of a niche thing, but some of us are M4 addicts.

C is in a pretty good place otherwise. I like to think there are 3 known local optima in terms of programming languages: C, Lisp, and Forth. All of them are a little hard at first, but quickly become very easy to think in.

We'll probably never get any of this, which is a little depressing. I get the feeling the C committee doesn't really care that much about evolving the language any more. Modern, fast, safe(-ish), readable code is a GCC extension.

1. http://www.gnu.org/software/libc/manual/html_node/Custom-Str... 2. https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md...

For aligned_realloc, you may want to look at using jemalloc for your code, instead of the vendor malloc. It's got an "experimental" function rallocm that does allow you to choose the alignment. Regarding m4 as a preprocessor, I'd rather wishlist a proper macro system for Cx+n that could do the job of the preprocessor and any other uses of precompiling.

The big problem with extending the C language is that C's in a ton of places. Some of the things you describe would mean increasing the size of the C runtime, which would be unacceptable in embedded programming and the like. Perhaps we need a middle ground language here -- more daring than C, more conservative than C++ -- where ideas can be tuned better and/or be specified for system types. C's universal assembly role really is a double edged sword as far as getting new stuff in the language.

I implemented my own, but I'll definitely check out jemalloc. I happen to have a use case for allocating large chunks aligned on large boundaries (high-performance garbage collector). jemalloc is common enough that I suppose it's not a particularly bad dependency.

Adding Lisp-style AST macros to C is never gonna happen[1], though it would be cool. I'm of the opinion that text macros and ‘real’ macros complement each other anyway.

One of these days I'll get around to implementing a less-portable-more-cool-C. There's Jai[2], but I don't really agree with all of its design (understandable, since I'm not a game developer).

--

1. Just kidding, people have done it already; e.g. https://github.com/eudoxia0/cmacro but it'll probably never be part of the standard.

2. https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md

I think your do-while suggestion is kind of cool, but I think that this program may do different things under a current C compiler and one which includes the feature you suggested.

    int x = something();
    do {
        const int x = somethingElse();
        ...
    } while (x != 42);

While some might claim this goes against the spirit of C, I think minor support for generics(enough to implement a type safe dynamic array e.g. vector) would be really useful. And if this did monomorphisation, then performance would still be great.

How about just type parameters that let you implicitly get sizeof parameters and pass function pointers without having to unportably cast them.

We already have C++, so is this required? If you want C with a dynamic vector, you could write C in C++ using std::vector.

While it's important to not overload C with features, not adding features to it because C++ already has it isn't very practical.

All I want is Friendly C. Eliminate unnecessary sources of undefined behavior, stop exploiting undefined behavior in ways that breaks sensible code, and give me sane semantics like two's complement signed integers by default.

http://blog.regehr.org/archives/1180