Comment by aidenn0 | Hacker News Reader

Comment by aidenn0 | Hacker News Reader

Given that it's SQLite, this is likely a compiler bug. However, the code given is insufficient to demonstrate a compiler bug. Given:

      c = pMem->flags;
      sqlite3VdbeMemRelease(pMem);
      pMem->flags = MEM_Str|MEM_Term|(c&(MEM_AffMask|MEM_Subtype));

You could have say:

    sqlite3VdbeMemRelease(struct foo pMem) {
        *(some_other_type *)&pMem->flags = bar;
    }

In which case the C aliasing rules would allow the compiler to assume that the assignment through "some_other_type" does not affect the assignment through whatever type pMem->flags is.

I have seen this bug happen before, when compilers got better at inlining, where it was something like

   void getAddressOfSomething(intptr_t *address);
   ...
   char *p;
   getAddressOfSomething((intptr_t *)&p)
   *p=foo

The compiler could reorder the \*p=foo line to be before the getAddressOfSomething call for the same reason.

TL;DR: Turn of strict aliasing via compiler flags (-fno-strict-aliasing on gcc) if you ever type-pun anywhere without using a union.

The code for sqlite3VdbeMemRelease can be found here: https://www.sqlite.org/src/file?name=src/vdbemem.c&ci=4218c7...

I don't see any type-punning of the flags going on. (The sqlite3VdbeMemRelease method doesn't touch the flags directly, but it calls vdbeMemClear which in turn calls vdbeMemClearExternAndSetNull which resets flags to MEM_Null.)

That's exactly what I expected. SQLite is one of the very few pieces of software where, when compiled on a new compiler, a bug is much more likely to be in the compiler than in the software it's compiling.

That's not because compilers aren't buggy; compilers have bugs. It's because most software is compiled with very few compilers and has fairly low ratio of effort invested in being correct vs effort invested in writing features. Neither of those are true for SQLite.

Notice that C allows you to introduce UB for sqlite3VdbeMemRelease in any TU of the program, not only the TU that defines it, so you'd need to check every declaration in the program at least, and that would include checking at least every file that includes its header file, making sure that, e.g., all defines are identical, among other things.

> Turn of strict aliasing via compiler flags (-fno-strict-aliasing on gcc) if you ever type-pun anywhere without using a union.

That's the topic of Gary Bernhardt's (of JS WAT and Execute Program fame) very important "A Case Study in Not Being A Jerk in Open Source". https://www.destroyallsoftware.com/blog/2018/a-case-study-in...

Linus actually matches the standard in that one, interestingly.

What an utter bullshit article. If people can't see the technical merit of an article past the swear words, they should stop working and join their convent of choice. Weaklings.

I think that is the entire point of the article.

> loses none of the meaning

It absolutely looses some meaning and important information conveying, and most importantly some impact factor.

Communicating by pretending you are in a neutral state of mind when you feel very strongly about a subject put everybody at risk of not understanding the perceived importance of it.

The rewritten email looks like corporate bullshit and is the kind of thing you risk to immediately forget. It looks like The PowerPoint slide that crashed a space shuttle https://medium.com/@JoachimLasoen/the-powerpoint-slide-that-...

It would have been way less distributed and discussed if originally written this way.

Now the original is maybe too much and, while a few repetitions are ok, it contains probably way too many. But there is probably a middle ground to be found between the original email and the rewritten one. For example, "AND STANDARD" in caps is perfectly fine if you want such strong emphasis on that point. Likewise for "documented" for emphasis but somehow less than caps. That makes no sense to pretend that such emphasis is a meaningless expression of anger; those are key point of the mail, called early on. I agree you probably want to avoid "f*ckin moron" and "braindamage", however there is no point in removing "piece of garbage" about this point in the C standard, and the precise point being talked about is contextually clear in the mail.

Reply on news.ycombinator.com