You might consider the int_fastN_t types a sort of spiritual successor to this with fewer downsides since they purposefully guarantee a minimum width.

I wonder if typeof in c23 has changed this at all. Previously there was no sense in defining an anonymous struct as a function's return type. You could do it, but those structs would not be compatible with anything. With typeof maybe that's no longer the case.

e.g. with clang 16 and gcc 13 at least this compiles with no warning and g() returns 3. But I'm not sure if this is intended by the standard or just happens to work.

    struct { int a; int b; } f() {
        return (typeof(f())){1,2};
    }
    int g() {
        typeof(f()) x = f();
        return x.a + x.b;
    }

Did you have any questions in particular?

The site contained a pretty amazingly comprehensive detailing of the game's mechanics and various algorithms scattered throughout the articles, to the point where it seemed to me like it'd be possible to implement a lot of the game's engine using it.

Some good examples of the more detailed articles:

The economy https://community.simtropolis.com/omnibus/other-games/the-ec...

Land value specifics https://community.simtropolis.com/omnibus/other-games/land-v...

Traffic and transportation specifics https://community.simtropolis.com/omnibus/other-games/traffi...

Zone development rules https://community.simtropolis.com/omnibus/other-games/zone-d...

  void *x = malloc(...);
  free(x);
  if(x); // undefined behavior

This special behavior is also specifically applied to FILE* pointers after fclose() has been called on them.

If there is some historical reason / architecture that could explain this part of the specification I would be interested to hear the rationale, this has been present in mostly the same wording since C89.

   clang --analyze --analyzer-output text ...

There was an analysis of this and the C++11 lambda specification done shortly after at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1483.htm, but it was inconclusive and there doesn't seem to have been any followup since then.

To be clear, this question is coming from the perspective of the acquirer, but perspective from the other side seems equally if not more valuable here.

Comments URL: https://news.ycombinator.com/item?id=20114756

Points: 2

# Comments: 0

   void f(char (*n)[255]);
   char array[6];
   f(&array);

This won't produce a diagnostic for f(NULL) like "static" does, but does have two properties that might be considered benefits:

1) The length is exact rather than a minimum.

2) The type of "* n" is still char[255], whereas a char[static 255] parameter is still a decayed pointer-to-char. Thus with the former sizeof(* n) behaves as expected inside of "f", yielding 255.

These are true of the array-in-struct method as well.

Since this as a whole is among the least consistently implemented and (arguably based on the number of questions it generates) least well understood aspects of the standard it's nice to see some authoritative efforts to clarify the intended behaviors.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2294.htm

- Supply multiple makefiles targeting different implementations

- Bring in autotools in all its glory (at this point you are depending on an external GNU package anyway)

- Or explicitly target GNU Make, which is the default make on Linux and macOS, is very commonly used on *BSD, and is almost certainly portable to every platform your software is going to be tested and run on. The downside being that BSD users need a heads up before typing "make" to build your software. But speaking as a former FreeBSD user, this is pretty easy to figure out after your first time seeing the flood of syntax errors.

https://github.com/hyp/flang

The name re-use was a bit confusing.

This was true of gif until the mid 2000s, well after it became popular.

So this does not do anything to manage different sessions clobbering each others' histories. The solution posted by zootboy will work together with this script however.