Ian Lance Taylor

> The articles I see on the sites you list are typically narrow, sensationalist, or self-serving.

I'm shocked that you would say that about LWN, or Ian Lance Taylor's blog, or Landon Dyer's blog, or James Hamilton's blog, or Google Research Videos. It's so far from reality that I feel compelled to ask if you've actually read them.

> many of them are written to gain votes on these sites, which are themselves advertising driven.

Or that. I mean, maybe Mark? Or Gruber? But can you seriously see James Hamilton or James Hague or Raymond Chen or LWN writing an article "to gain votes on these sites"? I mean, come on.

> But most of what gets posted on HN is junk.

True. But Byte published less than one article per day, and only a minority of its articles were of the high quality that we're talking about here.

> What you may not be aware of is that a well written technical magazine article takes weeks of research writing and careful editing, not to mention interviewing experts and preparing of graphics. Professional writers add breadth and perspective gathered from multiple domain experts and synthesize it to produce something with added value.

Well, I haven't written for Byte, but my limited experience writing magazine articles falls pretty far short of what you're describing there. Byte did have some pretty good stuff, it's true. But as often as not, professional writers synthesize those perspectives with errors and FUD.

And I'd like to point out that in…

Another note about .note.GNU-stack, from Ian Lance Tayler: http://www.airs.com/blog/archives/518

He has a 20-part series on linkers that may also be of interest, though I suppose since they were written some of the details may have changed:

Part 1: http://www.airs.com/blog/archives/38 ; Part 2: http://www.airs.com/blog/archives/39 ; Part 3: http://www.airs.com/blog/archives/40 ; Part 4: http://www.airs.com/blog/archives/41 ; Part 5: http://www.airs.com/blog/archives/42 ; Part 6: http://www.airs.com/blog/archives/43 ; Part 7: http://www.airs.com/blog/archives/44 ; Part 8: http://www.airs.com/blog/archives/45 ; Part 9: http://www.airs.com/blog/archives/46 ; Part 10: http://www.airs.com/blog/archives/47 ; Part 11: http://www.airs.com/blog/archives/48 ; Part 12: http://www.airs.com/blog/archives/49 ; Part 13: http://www.airs.com/blog/archives/50 ; Part 14: http://www.airs.com/blog/archives/51 ; Part 15: http://www.airs.com/blog/archives/52 ; Part 16: http://www.airs.com/blog/archives/53 ; Part 17: http://www.airs.com/blog/archives/54 ; Part 18: http://www.airs.com/blog/archives/55 ; Part 19: http://www.airs.com/blog/archives/56 ; Part 20: http://www.airs.com/blog/archives/57

Thanks! I was thinking it was a little lacking in depth with just that one part :)

For the lazy:

Part 1 - http://www.airs.com/blog/archives/38

Part 2 - http://www.airs.com/blog/archives/39

Part 3 - http://www.airs.com/blog/archives/40

Part 4 - http://www.airs.com/blog/archives/41

Part 5 - http://www.airs.com/blog/archives/42

Part 6 - http://www.airs.com/blog/archives/43

Part 7 - http://www.airs.com/blog/archives/44

Part 8 - http://www.airs.com/blog/archives/45

Part 9 - http://www.airs.com/blog/archives/46

Part 10 - http://www.airs.com/blog/archives/47

Part 11 - http://www.airs.com/blog/archives/48

Part 12 - http://www.airs.com/blog/archives/49

Part 13 - http://www.airs.com/blog/archives/50

Part 14 - http://www.airs.com/blog/archives/51

Part 15 - http://www.airs.com/blog/archives/52

Part 16 - http://www.airs.com/blog/archives/53

Part 17 - http://www.airs.com/blog/archives/54

Part 18 - http://www.airs.com/blog/archives/55

Part 19 - http://www.airs.com/blog/archives/56

Part 20 - http://www.airs.com/blog/archives/57

Best source I've read is Ian Taylor's blog about his work on the gold linker:

https://www.airs.com/blog/archives/38

"Once again, the goal is speed, in this case being faster than my second linker. That linker has been significantly slowed down over the years by adding support for ELF and for shared libraries. This support was patched in rather than being designed in. Future plans for the new linker include support for incremental linking–which is another way of increasing speed."

Just think of the apps that were written in early Unix days - simple single-purpose apps, probably just one source code file , just one obj and libc to link together, no shared libs et al.

The linker code just grew organically as new "must-have" features were added. Correctness of features was more important than speed esp. when spinning rust was a limiting factor.

> Why bother running through a destructor chain ...

The Gold linker (written in C++) doesn't ( http://www.airs.com/blog/archives/362 ): "[I]n the gold linker I often deliberately omitted destructors, because many of the data structures live for the life the program; in such a case, destructors serve only to slow down program exit."

However, there are some things that you really want to know happened when the process exits for any reason. If possible, you'd probably like your files closed in a way that allows them to be re-opened. That's easy to do with destructors. Destructors: they were always for more than just memory management.

Attribute (qualifier), or storage class?

https://www.airs.com/blog/archives/428

The use of 'const' in C is very much a mixed blessing; I certainly have experience of the 'const poisoning' issue. Possibly it would have been better as a storage class.

For bool, yes it was a useful addition. Especially for the cases where old code would have something like:

#define FLAG_A 1u
#define FLAG_B 2u
int has_flag_B (something *some) { return some->field & FLAG_B; }

and that was then combined with logic expecting 'true' to be 1; which could sneak in over time.