Live data from Hacker News

Linus Torvalds on aliasing

yodaiken.com

61–70 of 284 posts

Re: Linus Torvalds on aliasing

#61
post #50
post #18

Here is a slightly more readable version that's not white-on-white, half-pixel-thick text: https://lkml.org/lkml/2018/6/5/769

Reading on a 400dpi 300nits screen in a slightly dark room, the lkml link hurts the eyes significantly more. Reading on a shitty 96dpi 100nits screen from 2004 in a bright room, the lkml link is the more readable one. Another situation of the eternal issue of "we need a web standard for specifying relative contrast", not "make everything blinding #000 on #fff".

Or perhaps do not specify any dumb colours, let the browser do its job of presenting things.

Oh wait, you know you can switch CSS to default layout? Perhaps the browser could use an option to still apply layout but ignore formatting and colours.

Re: Linus Torvalds on aliasing

#62
post #57

Earlier quoted context omitted.

Agree with your points about the suit and Licensing. > Linux only took off thanks to SGI, IBM, HP, Cray seeing value reducing costs from their own in-house systems to something else. This seems unfair, Linux took off because it constantly kept getting improved and has more and more developers contributing to it. It didn't only take off because it was cheap, but it kept on improving. Also, the Elitist mindsets of some…

It is not unfair, because the majority of "developers contributing to it" are on those company payrolls, 8h a day during a full week. It would be just another BSD or Minix if it would be only university students and weekend coders working on it, and we would all keep using Solaris, Aix, HP-UX, Tru64, Ultrix.... As for security issues, it helps that Linus is against disclosing security bugs as such.

> It is not unfair, because the majority of "developers contributing to it" are on those company payrolls, 8h a day during a full week. Why don't the devs at those company contribute to BSD then? Care to reflect on this?

Re: Linus Torvalds on aliasing

#63
post #37
post #32

Can someone ELI5 what the issue is with type punning and union aliasing?

Suppose you want to look at the bits of a floating point number, as though it were an integer. The type punning way to do that would be to access a double in memory through an integer pointer: double d = 3.14; int64_t *p = (int64_t *) &d; // !!! int64_t n = *p; The union aliasing way would be to makeset the double field in a union and read the integer field back: typedef union { double d; int64_t n; } int_or_double;…

No, type punning via unions is a gcc extension.

The standard only allows reading a value as the type it was written with or as char, and an access as char is only good for copying. If a char access used different bit order, that would be OK according to the standard because you couldn't tell unless you violated the standard.

It seems every compiler will tolerate a memcpy for type punning, even though this isn't required.

Re: Linus Torvalds on aliasing

#64
i really wish a person many software engineers idolize or at least obviously respect and pay attention to, myself being excluded from these camps, didn’t communicate like a child.

it’s an embarrassment for the field.

Re: Linus Torvalds on aliasing

#66

I never really understood why people complain about Linus personality. If you don't like it go somewhere else nobody is forcing you to code for Linux. Fork it and make your own.

Linus shows this behavior more rarely rather than often (about once a month) and usually in the direction of people he knows can take a bit of a rant.

Re: Linus Torvalds on aliasing

#67
post #57

Earlier quoted context omitted.

It is not unfair, because the majority of "developers contributing to it" are on those company payrolls, 8h a day during a full week. It would be just another BSD or Minix if it would be only university students and weekend coders working on it, and we would all keep using Solaris, Aix, HP-UX, Tru64, Ultrix.... As for security issues, it helps that Linus is against disclosing security bugs as such.

> It is not unfair, because the majority of "developers contributing to it" are on those company payrolls, 8h a day during a full week. Why don't the devs at those company contribute to BSD then? Care to reflect on this?

MIT license, they don't need to.

How much code do you think they got back from Sony, Apple, companies selling routers with BSD on them?

Even Google prefers to build their own OS from scratch with MIT license (Fuchsia) than keep on using Linux for that effort. They already reduced GPL use to the bare minimum on Android by removing gcc.

Then there was the whole suit which made most companies loose interest to be involved with BSD.

Re: Linus Torvalds on aliasing

#68
post #37
post #32

Can someone ELI5 what the issue is with type punning and union aliasing?

Suppose you want to look at the bits of a floating point number, as though it were an integer. The type punning way to do that would be to access a double in memory through an integer pointer: double d = 3.14; int64_t *p = (int64_t *) &d; // !!! int64_t n = *p; The union aliasing way would be to makeset the double field in a union and read the integer field back: typedef union { double d; int64_t n; } int_or_double;…

AFAIK even using union for the above purpose can be seen as "undefined behavior" when reading standard, and that's why the standard is especially wrong, as it makes some typical desired (and needed) outcomes impossible to implement, and at the moment clang still has problems even with the union variant whereas gcc allows you to use union by passing the compiler switch which effectively has the semantics "we promise we won't listen to the standard in this case."

That's why Linus writes:

"So the commit message that talks about how horrible union aliasing is is pushing a story that is simply wrong."

The commit message with which he disagreed obviously explicitly wrote something like (paraphrasing) "using union is undefined behavior by standard, so we are changing the code to not use it" etc.

Linus also wrote: "I'm not talking about the changes themselves - I can live with them. But the _rationale_ is pure and utter garbage, and dangerously so."

The rationale was (note, I don't have exact quote, I'm paraphrasing, if somebody has the original please give a link) that using unions for that is bad as per standard. Which is what the standard says but which is for practical purposes simply wrong. The standard is wrong an should not be followed, that was main Linus' argument.

Re: Linus Torvalds on aliasing

#69
post #63
post #37

Earlier quoted context omitted.

Suppose you want to look at the bits of a floating point number, as though it were an integer. The type punning way to do that would be to access a double in memory through an integer pointer: double d = 3.14; int64_t *p = (int64_t *) &d; // !!! int64_t n = *p; The union aliasing way would be to makeset the double field in a union and read the integer field back: typedef union { double d; int64_t n; } int_or_double;…

No, type punning via unions is a gcc extension. The standard only allows reading a value as the type it was written with or as char, and an access as char is only good for copying. If a char access used different bit order, that would be OK according to the standard because you couldn't tell unless you violated the standard. It seems every compiler will tolerate a memcpy for type punning, even though this isn't requi…

Does this mean that memcpy() is really more of a language construct than a library function, since it cannot be implemented correctly in fully defined standard C?

Re: Linus Torvalds on aliasing

#70
post #34

To me, this rant seems more directed at C standards people than the guy he sent it to. That doesn't excuse his vitriol, but I hope people will read between the lines. Sometimes people forget that C was created for writing operating systems. They get in their mind that C is all about high-performance, and that making it competitive with FORTRAN is the way to go. I understand that, but it's not what C was created for.…

Yes. From the article: " The standard simply is not important, when it is in direct conflict with reality and reliable code generation."
Post reply on HN