0x09

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/

I've done a similar thing with https://github.com/0x09/watch

It's extremely simple but it allows me to do things like plot a color coded calendar of app usage, which can provide very revealing info about things like productivity spikes and lulls or sleep schedules.

I have a companion Safari extension for tracking active tabs which I did not release since it seemed like such a niche and strange thing to use, but the main code to do that is simply https://gist.github.com/0x09/d1220a7b0a0bda64b4f542067cd43ec...

I've gotten myself into a stupid situation where I have purchased something like 4 adapters that don't accomplish what I thought they would when I bought them.

USB-C to DisplayPort -> DisplayPort to HDMI -> Monitor - doesn't work

USB-C to DisplayPort -> DisplayPort to DVI-D -> Monitor - doesn't work

USB-C to Ethernet - doesn't work

I'm actually planning to just go to Best Buy today and try to find anything that will let me plug this into my old monitor here even if it has to be the official USB-C to VGA cable from Apple since I don't have time to wait for shipping at this point.

I suppose this is my own fault but somehow I've never had this kind of problem in ~20 years of using a computer.

Edit: There are also currently very few resources about compatibility between all these new adapters and Apple hasn't done anything to help in their spec info so it's really just a guessing game right now.

I published a set of utilities that I developed for playing and to help myself learn about frequency analysis here, you might find them interesting:

https://github.com/0x09/dspfun

It is an open standard. Anyone can purchase and implement it, and it was developed by ISO. The technologies are not royalty free in the US. Don't conflate the two. *

Edit: I emphasize this mainly because the terms have a specific meaning in standards jargon but also because it places the blame for software patent abuses on the wrong parties (the standards developers rather than the lawyers and legislators).

> I'm certain you will never see ads in MacOS as part of the OS "features."

How certain?

http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=H...

Remember that a brickwall band pass filter (low, high, or anywhere else) is equivalent to convolution with this https://www.dsprelated.com/josimages_new/mdft/img1768.png in the spatial domain. Any time quantization is high enough for coefficients in a given band to become zero while the surrounding ones remain nonzero it will introduce at least some level of ringing.

wyager accurately described why in terms of the DCT though -- cosines naturally "ring" and the only way a non-sinusoid can be represented is through the combination of many other terms, so any time a coefficient contributing to this shape is eliminated, the structure "decays" so to speak and the underlying sinusoids become part of the reconstruction.

This, the standard document itself (it's not very long, and drafts are freely available), and the C tag on stackoverflow (often contains comprehensive answers by well informed people) are my recommended resources.

http://port70.net/~nsz/c/c11/n1570.html

http://port70.net/~nsz/c/c11/n1570.pdf

http://stackoverflow.com/questions/tagged/c

A good way to casually browse SO for interesting information is filtering by questions in the last <time period> and ordering by votes.

http://stackoverflow.com/search?tab=votes&q=%5bc%5d%20is%3aq...

It's cheaper not to if you take less than 14 rides a week, which is not unusual at all in places like the East Village.

Late reply but you can actually do this with the library as is. It's not designed for it so you'll have to use fftw yourself and call some borderline internal stuff, but it ought to work the same.

    float* samples = ... //load audio samples here
    int len = ...
    fftwf_plan p = fftwf_plan_r2r_1d(len,samples,samples,FFTW_REDFT10,FFTW_ESTIMATE);
    fftwf_execute(p);

    RDResolution* res;
    size_t count;
    RDMethod* m = resdet_methods();
    m->func(samples,len,1,1,&res,&count,12,m->threshold);

That's exactly how it works. The example doesn't show more than one, but it will return multiple resolutions ranked with a confidence percent (the meaning of which depends on the method) as long as it's above a reasonable threshold.

Usually multiple results are a misdetection -- for example heavily compressed JPEGs will mess it up pretty badly:

    $ convert Lenna.png -quality 50 Lenna.jpg
    $ resdet Lenna.jpg
    given: 512x512
    best guess: 448x384
    all width        height
      448 (77.49%)     384 (90.19%)
      384 (66.99%)     448 (89.78%)
      320 (60.68%)     320 (72.54%)
      388 (55.92%)     256 (56.43%)
      445 (55.49%)   
      345 (55.47%)   
      242 (55.06%)   

(the block-based nature of JPEG compression/quantization creates a similar zeroing effect along every 1/8 of the spectrum)