dtzWill

Title has a typo, should be "RISC-V", not "Risk-V".

> and gets updates

Wife and I also have pixel 2's, and AFAIK October 2020 was the last month we got updates[1] :(.

(although it notes "Pixel 2 Preferred Care customers have telephone support until April 2021.")

Which makes this article all the more disappointing, as we're looking to upgrade for this and the usual reasons :).

[1] https://support.google.com/nexus/answer/4457705?hl=en

This is actually an area of very current research. We have implemented a form of software multiplexing that achieves the code size benefits of dynamically linked libraries, without the associated complications (missing dependencies, slow startup times, security vulnerabilities, etc.) My approach works even where build systems support only dynamic and not static linking.

Our tool, allmux, merges independent programs into a single executable and links an IR-level implementation of application code with its libraries, before native code generation.

I would love to go into more detail and answer questions, but at the moment I'm entirely consumed with completing my prelim examination. Instead, please see our 2018 publication "Software Multiplexing: Share Your Libraries and Statically Link Them Too" [1].

1: https://wdtz.org/files/oopsla18-allmux-dietz.pdf

You might have misunderstood "postInstall" -- rather understandably so since elsewhere (debian packages, ...) for precisely the issue discussed in the article: arbitrary scripts executed after package installation.

In Nix postInstall (and preInstall, as well as preBuild/postBuild, etc) specifying commands to execute before/after the corresponding "phase" -- so if a package is "almost" good to go with just "make install", you could use postInstall to do something like copy a file omitted by upstream's installation target.

The point is that postInstall in Nix is part of how the package itself is constructed-- in contrast to commands run after installing the package. There is no equivalent for this in Nix in a fundamental way (not by policy or for technical reasons).

And in particular guix uses nix internally-- but (AFAIK) at an API level and very little of the nix language.

So it's rather related for that reason :).

If what you're dealing with is actually a git repository, in 2.0 you can just use "src = fetchGit ./.;"-- this is what the expression for building Nix itself does :).

Otherwise you can use filterSource (documented in the linked article, the Nix manual) to roll your own filtering.

If you have any problems with either of these I encourage you to join #nixos on freenode and ask. Hope this helps! :)

FWIW jwz redirects to something unfortunate, here's the same page via nullrefer.com which seems to do the trick:

http://nullrefer.com/?www.jwz.org/doc/cadt.html

and on archive.org:

http://web.archive.org/web/20170702194030/https://www.jwz.or...

Not sure what "the ccc" is (if it's not "corkami") but your comment and parent's led me to finding this treasure-trove of format visualizations:

https://github.com/corkami/pics/blob/master/binary/README.md

Lots of good stuff here!

This is good advice, and understanding this is the key to interacting with 'hacker' types.

A good document to read or link from your project's "Contact" section is this FAQ on asking smart questions:

http://www.catb.org/esr/faqs/smart-questions.html

It might not be quite right for your project but for many projects I've been part of it's pretty spot-on, at least as a starting point to avoid the worst of the 'bad' questions. Our IRC bot had a command for linking this to people, haha O:).

Related: http://bash.org/?152037

Author here. FWIW the linked paper is the extended edition as published in TOSEM 2015, not the original ICSE 2012 paper, which I was surprised by given the year in the subject.

That said, I'm glad this edition is getting a bit of attention as we were able to be more thorough given the longer format (as well as more time), including an automated study of the top 10k Debian packages. The paper details what's new in more detail.

Let me know if you have any questions or comments.

May your integers be safe!

1) Challenges in understanding undefined behavior are exactly why tools like ubsan[1] exist. In a way they help /everyone/ understand when 'undefined' constructs are encountered, and having this emitted by the compilers responsible for translating your source code into binary code is the ideal place.

2) Compilers leveraging undefined behavior knowledge get a lot of hate for breaking this implicit contract defining what they "should" do as expected by programmers. Unfortunately these feelings are rather misguided, compilers are just doing what they can to produce the best code for you using the explicit contract that exists: the language specification(s). Are these specifications perfect? No, but they're what we have. If someone were to define a new language that actually captures the assumptions "real" programmers "expect" when they write code then compilers could choose to support it (and probably would!) and everyone would be happier. Until then this is a big case of "how come you're not doing that thing you never said you'd do and no one is willing to define properly?" which is a bit silly. Imagine you're a compiler developer: what assumptions CAN you make to satisfy everyone? In short, compiler developers aren't your enemy, they're just doing everything they can to produce the best code they can for you.

2a) Use of -f* is in a way used to define that a special variant of a language is desired, for example -fwrapv builds the code using an unnamed variant of C where signed integer overflow is well-defined.

[1] http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

You might want to use wego[1] directly if you're interested in weather reports in your terminal, if the dependencies aren't an issue.

[1] https://github.com/schachmat/wego

Nothing, really.

There's an argument that using a 'for' construct groups together the details of the loop (initialization, the loop condition, iteration update), which can aid readability.

(You don't have to search the loop body to find how things change between iterations)

Of course, nothing forces a for() loop to have iteration behavior entirely dependent on only what's in the 'for'. In my experience this seems to be discouraged, however, preferring to use 'for' only when there is a predictable and simple iteration pattern.

In the end, it's just a matter of preference and style. :)

I created an account just to upvote this, very cool and keep up the good work! :)