etyp

Ah, I used EDG for static analysis, but joined when we were switching over to using Clang for the frontend. I can't say for sure, but part of it was definitely just to save money using open source. The code that was hacked on top of EDG was also ridiculous, so there was a lot of accumulated tech debt there.

Looking back at that code definitely brings back memories. As a consumer of both frontends, I will say I much preferred working with Clang's. Both needed extra work on top to support everything we needed. Maybe I'm just not as acquainted with C as I would like to be. It's cool to look at this again, though.

To quote the very first paragraph of the bytecode interpreter section[1]:

> The style of interpretation it uses—walking the AST directly—is good enough for some real-world uses, but leaves a lot to be desired for a general-purpose scripting language.

Sometimes it's useful to teach progressively, using techniques that were used more often and aren't as much anymore, rather than firehosing a low-level bytecode at people.

[1] https://craftinginterpreters.com/a-bytecode-virtual-machine....

There is a chance that the title here was intentionally worded to answer a question people are likely to search for, then actually answer their concerns.

This is one of those natural consequences of "everything is an expression" languages that I really like! I like more explicit syntax like Zig's labelled blocks, but any of these are cool.

Try this out, you can actually (technically) assign a variable to `continue` like:

let x = continue;

Funnily enough, one of the few things that are definitely always a statement are `let` statements! Except, you also have `let` expressions, which are technically different, so I guess that's not really a difference at all.

Yeah I only found day 2, hopefully day 1 will appear though: https://www.youtube.com/watch?v=ZLRngpdV6Qg

(edited to not assume anything)

is ,AOE too far?

I read it as "this was a big news story which we care about. You may know it, but it is not the primary reason. Here is the primary reason."

Random note since Godbolt was mentioned: It's also fun to hop on play.rust-lang.org and see what different IRs look like via the "..." next to "RUN." Just look at how simple the HIR is pretty simple for "Hello world" - then check out the MIR ;)

This goes to show how Zig's language design makes everything look nicer and simpler - the `errdefer` patterns in tests are super nice! I've debugged my Zig tests with simple print debugging (or try to narrow it down to a standalone case I can use a debugger), but I'll certainly use some of these tricks in the future.

Zeek is well known in "security" spaces, but not as much in "developer" spaces. It did get me a bit excited to see Zeek here until I realized it was unrelated, though :)

Practically, it's all through this `type_traits` header that (often) end up in unreadable messes. It's all possible because of the catchy acronym SFINAE. It doesn't make much sense to me either, so I avoid it :)

https://en.cppreference.com/w/cpp/language/sfinae

The Real Book was pretty fundamental helping me learn jazz. I think a lot of jazz people look down on it (or those who need it), but I didn't really get deep enough to see that. There's a short video from Adam Neely that opened my eyes to that a bit.

https://youtu.be/dD0e5e6wI_A?feature=shared

I really love that static analyzers are pushing in this direction! I loved writing Clippy lints and I think applying that "it's just code" with custom checks is a powerful idea. I worked on a static analysis product and the rules for that were horrible, I don't blame the customers for not really wanting to write them.

Is there a general way to apply/remove/act on taint in Go checkers? I may not be digging deeply enough but it seems like the example just uses some `unsafeVars` map that is made with a magic `isUserInputSource` method. It's hard for me to immediately tell what the capabilities there are, I bet I'm missing a bit.

I like how this is structured. When I read that inline types get copied-on-borrow I was pretty put off. Then since fields of inline types can't be assigned new values it seems a bit better, as long as you roughly know what's happening. Hopefully the diagnostics are good enough there. I like the detailed alternatives that weren't chosen.

I appreciate being able to choose which side of the tradeoff (always-copy or heap allocated) you want to be on, but either way be assured it's safe. Not sure how I feel about it in practice without trying it, though :)

I've actually tried serializing languages into protobufs. The main reason was it made communication from X random programming language to Java in a consistent, structured way. Seems like it's just how they sent the IR from OCaml to C++. On either side you'll get the Bolt IR so I don't think debugging suffers too much. But the extra step for serializing and deserializing is a bit of a bummer

I'm excited to see how that x86 backend is, I haven't tried it yet. It's definitely an interesting step for a new language to do on its own

Seems reasonable enough, but why would it (allegedly) send environment variables back via a POST? Even if it's entirely in good faith, I'd rather some random package not have my `env` output..

Nietzsche is a very interesting example since there is a very obvious shift in his philosophy from The Birth of Tragedy to, say, The Gay Science. I understand the argument that the style of writing noticeably changes, and I'd be okay attributing that to "automated writing," but a lot of the shift in Nietzsche's work feels like a pretty drastic shift in ideology. I'm not convinced that shift entirely, or even largely, comes from the shift in medium.

Safe programs extend beyond those that Rust's borrow checker accepts though. There is more than one way to make a program safe, not all of them would be valid Rust.

I don't think the C++ standard can be held up like that. Many compilers simply ignore it (or ignored it, they're getting better about these things). It's not because there's an omission, it's because writing a compiler that conforms to a thousand page document of rules is hard. And tedious. Some will fall through, there is no "one true C++" that follows the standard perfectly, most fall short. The ambiguity is still there, many times you can read the standard and know what the compiler will do, but many times you can't. Even if the standard is unambiguous.

So with Rust, the implementation is the specification. The author mentioned gccrs - hasn't that already had some positive standardization benefits without a true standard? I'm not super knowledgable about the status there, though.

I feel like more standardization is certainly worthwhile, but writing a specification is an entirely different beast. I see that as years of painstaking work just to keep everything mostly the same and harder to iterate. Seems like a hard sell even if it would be great for systems programmers ;)

> For developing external code analysis tools such as Coverity

You can do that by just using intercepting `rustc` and using the static analysis tool's common IR(s), right? I'm nitpicking here, though.

Yeah, I've never really considered using a grammar like that for string processing like they suggest. And it's the first thing they show. Maybe I'm missing out and I just haven't had the tooling.