News for hackers. Stuff that matters.

0x09

Re:Why is int in C in practice at least a 32 bit? on Thursday November 09, 2023 @09:00PM (#38214186)
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.

Re:C’s Biggest Mistake on Sunday July 02, 2023 @09:25PM (#36567623)
>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).
Re:sqlean: A set of SQLite extensions on Tuesday February 28, 2023 @11:45PM (#34978871)
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?

Re:GitHub-Next on Friday August 26, 2022 @04:03PM (#32612104)
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
Re:The ideology hiding in SimCity’s black box on Sunday April 04, 2021 @03:30AM (#26687574)
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...

Re:Pointers Are Complicated, Or: What's in a Byte? (2018) on Saturday September 05, 2020 @08:46PM (#24388011)
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)."
Re:Pointers Are Complicated, Or: What's in a Byte? (2018) on Saturday September 05, 2020 @07:23PM (#24387645)
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.

Re:GCC 10.1 Released on Thursday May 07, 2020 @08:33PM (#23110034)
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.
Re:Tell HN: C Experts Panel – Ask us anything about C on Tuesday April 14, 2020 @09:46AM (#22865865)
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?
Re:Lambdas for C – sort of on Wednesday September 11, 2019 @08:27PM (#20946277)
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.

Ask HN: Resources for First Time Acquisitions

A friend has been tasked with orchestrating the merger between two similar (small, together bordering on mid-size) competitors. The actual terms of the deal have already been scoped out by the respective CEOs; what's left is really everything else. Are there any good resources or pieces of insight the HN community can offer for someone, and a company as a whole, going through this for the first...

( Read More... | no comments | 2 points | on HN )
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.

Re:C2x: the next real revision of the C standard on Monday November 12, 2018 @09:24AM (#18432729)
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

Re:The End of Video Coding? on Wednesday June 13, 2018 @06:52PM (#17307695)
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)
Re:A Tutorial on Portable Makefiles on Sunday August 20, 2017 @05:56PM (#15060443)
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.
Re:A Tutorial on Portable Makefiles on Sunday August 20, 2017 @05:02PM (#15060240)
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.

Re:Flang – A Fortran compiler targeting LLVM on Thursday May 18, 2017 @09:59PM (#14372512)
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.

Re:strncpy() is not a safer strcpy() (2012) on Saturday April 29, 2017 @02:52PM (#14228099)
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.

Re:Historian: Because Please Stop Deleting My Bash History on Thursday April 13, 2017 @12:14AM (#14104119)
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/

Re:The idea maze of personal logging (2016) on Sunday February 19, 2017 @02:19AM (#13678542)
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.

Re:H.264 is Magic on Friday November 04, 2016 @10:32AM (#12872815)
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

Re:H.264 is Magic on Friday November 04, 2016 @08:22AM (#12871985)
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).

Re:Microsoft Delivers Another Broken Windows 10 Update on Saturday October 01, 2016 @02:55PM (#12619338)
> 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...

Re:Image Compression with Neural Networks on Thursday September 29, 2016 @07:56PM (#12609706)
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.

Re:To become a good C programmer (2011) on Sunday May 01, 2016 @02:07PM (#11607174)
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...

Re:NYC subway math on Thursday April 07, 2016 @07:50PM (#11451614)
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.
Re:Show HN: Detect upsampling in images on Thursday January 21, 2016 @10:56AM (#10946041)
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);

Older »