0x09's comments

It's partly an artifact of BCPL where the only type was one representing the machine word. So with a word-sized type you don't get portability in the range of values the type can represent, but can portably know that you won't e.g. take up 2 registers by using it.

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.

>Can be macro'd at the function definition, but it's ugly.

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;
    }

edit: though I suppose this just pushes the problem onto callers, since every function that does this now has a distinct return type that can only be referenced using typeof(yourfn).

I'm the author of the extension that the vtab and define function in that module were adapted from. It allows you to create something like a parameterized view, but the way it works is fairly simple: a prepared statement is created from the provided SQL on the same db connection as the vtab, and is executed each time the virtual table is queried. Parameters can be supplied as constraints (or using table valued function syntax) and the results of executing the statement are the row values.

Did you have any questions in particular?

Doxygen has the ability to generate these with its CALL_GRAPH/CALLER_GRAPH config, at least from each function individually. It can look quite funny when the depth isn't limited: https://i.imgur.com/3LMV71N.png

Something of an informal reverse engineering of SimCity 3000 existed in sc3000.com's Knowledge Neighborhood. The original site is only partially available via the wayback machine now, though fortunately the articles have been preserved albeit in a slightly less convenient format here https://community.simtropolis.com/profile/157989-catty-cb/co...

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...

This and Annex J.2 Undefined Behavior and Annex L.3 Analyzability Requirements both also specifically include: "The value of a pointer that refers to space deallocated by a call to the free or realloc function is used (7.22.3)."

The article doesn't touch on this, but in C pointer types are also the only kind that can be invalidated without any apparent change to their value:

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

Note that this isn't about dereferencing x after free, which is understandably not valid. Rather the standard specifies that any use of the pointer's value itself is undefined after being used as an argument to free, even though syntactically free could not have altered that.

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.

Though scan-build is usually the simpler option, clang itself does have an --analyze flag which writes analysis results in various formats, including the same html reports that scan-build would generate. But to see this on standard out

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

Will print the entire analysis tree in the same format as regular diagnostics.

Not about the language exactly, so maybe not fair game, but: how did you all find yourselves joining ISO? And maybe more generally, what's the path for someone like a regular old software engineer to come to participate in the standardization process for something as significant and ubiquitous as the C programming language?

Apple did submit a proposal based on the then-new blocks extension in 2010: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1451.pdf

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.

I like using pointer-to-array types for this purpose as (like an array in struct) the array's length is encoded in the type, and thus likewise allows the compiler to warn if an incompatible array is provided. e.g.

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

warns of "incompatible pointer types passing 'char (* )[6]' to parameter of type 'char (* )[255]'"

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.

The linked discussion on the memory model is particularly interesting to me as it covers a number of issues and ambiguities with the current specification for strict aliasing and what kind of accesses should/shouldn't be allowed, including for example the problem that there's no way to obtain untyped space on the stack (Q75).

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

This is known as scalable coding and has been included as an extension or profile in at least every ISO and ITU standard since MPEG-2, see for example https://en.wikipedia.org/wiki/Scalable_Video_Coding (this article seems to be specific to H.264)

Putting the logic into a more flexible configure script that generates definitions for your Makefile and imitates the autotools build process without actually using autotools is a good/obvious compromise. Even some large projects like FFmpeg and mplayer/mpv do this.

The problem comes in as soon as you need conditionals, which is likely when attempting to build something portably. There may be some gymnastics that can be done to write around the lack of their presence in standard make, but otherwise your options are:

- 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.

Apparently unrelated to Flang the 2013 LLVM GSOC project to implement a Fortran frontend.

https://github.com/hyp/flang

The name re-use was a bit confusing.

The code copies the origin string up to and including the null terminator, which must exist as strlen was used to obtain the size.

> You can't just have an mp4 (well, x264) file because that's patent-troubled.

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

Looking at the script, it doesn't write any history itself, it just loads whatever is in the existing .bash_history into its db when `hist import` is invoked (when a new shell is started if you add it to your .profile like the readme recommends.)

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.

The BSDs, Windows, OS X, and Mac OS classic and their corresponding filesystems all supported this for decades. Linux is the only major holdout, because according to Linus, "it's all totally useless and people can't even agree on a name." [1]

[1] https://lwn.net/Articles/397445/