Björkus "No time_t to Die" DorkusOh cool, another Chrome 0-day abusing integer overflow.
Neat.
Great.
Awesome.
Meanwhile, we'll be writing about how we need to have "high impact libraries that help lots of users" and then give examples like CLI Parsing/JSON Parsing before we sit down and go "we should have some standard library types / functions for integers...?".
v.v.v.v. cool prioritization we do here.
We keep calling ourselves software engineers, but engineers elsewhere advance their industry by analyzing failures and building up tools to stop those and make them standard industry practice!
But we'll just have the same 6 problems, on a regular spin cycle, for like 40 years.
Chris@thephd The analyzing and tool building started very early and never stopped, but making them praxis has been weirdly modal. In your analogy, it's like we build cottages and sheds out of reinforced concrete and high-grade steel, but insist on building our longest bridges and tallest sky scrapers out of clay and wood.
Gina Peter Banyard@thephd The thing that is also different in other industries is that the *engineers* are held liable for them signing off, be that in writing or even verbally, on designs.
Meanwhile, in software, we just don't give a flying fuck about it because the consequence of our decisions are going to be felt not by us but by some other random person.
And we even encourage this behaviour, by promoting people that "just ship" shit instead of people that reliably test and think about their choices.
Matt Palmer@Girgias I put a lot of blame on the ability of software makers to disclaim all liability. I can't think of another product category that is able to say "no matter how egregiously bad our product is, any damage it causes is totally not our fault".
Kaitlyn@Girgias @thephd Fun fact, the term "software engineer" is protected in Canada, and genuine Canadian software engineers are held to the same level of liability as other engineers. Big tech companies have gotten in trouble with regulatory bodies over this & change their job titles for Canadian postings
Craig Francis@Girgias @thephd Yep, we just keep looking at the same issues over and over again, and don’t really do anything about them… e.g. most programmers should use memory safe languages, and Injection vulnerabilities should be a thing of the past https://eiv.dev
David Nash@thephd I’ve said before that I’m undecided on whether or not “engineer” is an appropriate title for people working in routine software development and design, but also that people who do want to use the title absolutely should take the time to learn about engineering failures in multiple disciplines. Software failures like the classic Therac-25 fuckup are bare minimum table stakes; it’s a good idea to find something else (ideally, several different types of something else) and learn more about how people addressed those failures, learned from them, and made sure they (and other related cases) didn’t keep happening.
@thephd Here's a concrete (no pun intended) example of a very basic fuckup that should have been caught, wasn't, and killed a bunch of people: the Hyatt hotel suspended walkway that collapsed during an event with hundreds of people, killing over 100 and injuring over 200 more.
The cause? A sudden design change that was inadequately discussed and reviewed, which caused the walkway to support twice the load of the original design, which *itself* was not fully up to proper design specs. The engineer who signed off on the original plans later said "any first-year engineering student could figure it [the error] out." https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse
@thephd One of the outcomes of *this* fuckup: normalization of the idea that (from the article above) "structural engineers are now ultimately responsible for reviewing shop drawings by fabricators." This was the position adopted by the American Society of Civil Engineers as a direct result.
LisPi
Eric Jennings@thephd @baldur yeah. I’m very jealous of my friends who went into actual engineering. I mean there’s plenty to gripe about everywhere and the MBAs screw us all, but when I see the way we’re constantly shooting ourselves in the software world I really wish I had done something where people build something durable and real.
jsj
Not a Spring OnionOh, they definitely do. At one department I knew, there was a research project for aligning data in memory to "look tidier".
No, nobody could explain what that would be good for. 
(This was not about memory alignment or paging or effective use of space.
It was literally a GUI program that allowed users to align little memory rectangles on a 2D canvas.)
Nuclear Oatmeal 
@thephd Oh, but we'll create a new framework or API or maybe... update a standard?
That'll solve the problem.
Florian Schroiff 
@thephd a “website” can be a supermarket brochure or a bank or a diary or medical services. And we treat all of those with the same engineering rigor.
Martin Ruskov@thephd what stops you software engineers from reflective practice and finding ways around these problems? Bertrand Meyer did it
Christian Wolf@thephd ever tried issuing a patch for a bridge? Most software today can be “fixed” in a jiffy. That lowers the quality bar tremendously, and thus, also the costs.
Geert Uytterhoeven@chaos0815 @thephd Bridges are being patched all the time.
Unless they're not.
https://en.wikipedia.org/wiki/Ponte_Morandi?patch
Unless they're not.
https://en.wikipedia.org/wiki/Ponte_Morandi?patch
DCoder 🇱🇹❤🇺🇦@thephd
Tom Simpson’s “Masterpiece Engineering” is 55 years old and it is still painfully accurate.
Tom Simpson’s “Masterpiece Engineering” is 55 years old and it is still painfully accurate.
CyberFoxar@thephd tbh, most of software crafting is more akin to artisanal craftmanship: highly technical, very personal, with a less-than-ideal result.
The title of "Engineer" does not fit 90% of what I do, but "Software Artisan" does not ring a bell to anyone.
The Engineering part of Software Engineer happens very early in development, near the planning phase. It's when technology choices are made, architecture is chosen, and such. Not when the actual coding happens.
Software engineers are expected to code too, which is unusual when compared to other industries: You do not ask a production engineer to actually build and assemble a production line, not do you ask a logistics engineer to do delivery runs themselves.
Yet, software engineers do the planning, the ideation, the problem solving and the implementation. In that way, it's more of an artsan/craftmanship job than other engineering jobs.
Oborosaur@thephd I always found this (and follow-up) post an interesting treatment of this question.
https://www.hillelwayne.com/post/are-we-really-engineers/
I was somewhat surprised that one of the conclusions appears to be "it's just as bad in ((other engineering discipline))" by some oft-cited measures.
Are We Really Engineers?
This is part one of the Crossover Project. Part two is here and part three is here. A conference talk based on this work is now available here. I sat in front of Mat, idly chatting about tech and cuisine. Before now, I had known him mostly for his cooking pictures on Twitter, the kind that made me envious of suburbanites and their 75,000 BTU woks. But now he was the test subject for my new project, to see if it was going to be fruitful or a waste of time.
moved to @
Astatide@thephd I can never decide if the problem lies more on the engineering or the management side (or whether that's a more modern problem in the more dystopian corporate hell we have today).
I do know a number of people who absolutely hate this, but at least for people in the industry, there's no ability (without unions) to refuse ridiculous requests from management such as throwing away whole ass useful closed source tools just because the C suite saw a new shiny.
prozacchiwawa@thephd by fits and starts i think we're getting there. things like CI and coverage based testing are very normal now.
my vision of the future is one where "you're able to write what you can prove" and i think we'll get there too in time as tools for automatic proof assistance get better and the ux of languages with proof systems get better.
Chip Collier@thephd it’s enormously frustrating to me on a daily basis. The tension between doing something correctly with patience and doing something in the artificial timeframes established by “business” interests is exhausting.
I feel like I’m being driven off a cliff by capital interests. And not by like any single human, I mean it’s a weird cultural feedback loop at work.
I feel like I’m being driven off a cliff by capital interests. And not by like any single human, I mean it’s a weird cultural feedback loop at work.
@thephd The funny thing is that I can think of at least two languages standardized since at least 30 years that have long solved this sort of problem (or at least, any implementation of the standards that has these issues is non-compliant/broken as far as the standard specification is concerned).
So this isn't so much "we don't fix the problems", it's "we refuse to even use the fixes because lolidunno".
So this isn't so much "we don't fix the problems", it's "we refuse to even use the fixes because lolidunno".
mgattozzi@thephd "No way to prevent this." says industry where this regularly happens
Luis Villa@mgattozzi @thephd need a 😬 action in Fediverse
Richard Hendricks@thephd I say the same thing every time I have to clear space in my brain for line endings.
Scott@thephd @irenes As the story goes, it was Margaret Hamilton who originated the term, and it’s made much more sense to me since I learned that. The way NASA approaches programming does in fact resemble traditional engineering. Not her fault the rest of the industry glommed onto the term for a little reflected glory.
Mark Levison@thephd my favorite Null.
Robert Kist 🇦🇹🇸🇬@thephd I remember a time where programmers were just called programmers, and then suddenly, everyone became an "engineer"
Robin Syl 🌸
@thephd but I WANT to be an engineer. I just wish my workplace would support that mindset
Nafeon (Backup Account)@thephd that's why I support moving core libraries to rust, zig and julia. They are languages which actually try to fix core issues.
I would actually be fine if we make a breaking change in C# and Java and make them nullsafe for example. Yes you wouldn't be able to compile an old program with it, but it seems so extremely neccessary.
"tep" ✅@thephd You mean, like the first description of a buffer overflow was in the "Anderson Report" around 1965? And that lead to things like hardware bounds checking (Multics), languages with bounded strings and arrays (PL/1, Pascal, Modula), and run-time range checking? And the C came along and...
vitaut 🤍❤️🤍 🇺🇦@thephd if only this was solvable by a library
@vitaut for all the building and packaging we're just oh so good, yeah sure. if only fundamental program properties were taken care of by the language rather than relegated to librarians
Paul Cantrell@thephd
Swift really got this one right IMO:
+ - * / all trap on overflow.
If you want mod-2^n operations, there are entirely separate operators for that: &+ &- &* &/
There is no implicit conversion between ints of different bit widths, or between ints and floats (in either direction).
Literals implicitly take the contextual type, so there’s no need to explicitly cast, say, `17` to assign it to an Int8 or a UInt64.
Hard to accomplish this consistency anywhere except at the language level.
Ed Davies@inthehands @thephd Better still, actually use the type system. If you write:
i = j * k
then make sure, at compile time, that the type of i can hold the result for any possible values for the types of j and k.
And uint16, etc, aren't types; they're implementations/representations of types. The types we should be using would be something like 0..65536 (or better some number which makes sense for the application rather than an arbitrary number because we happen to be running on a binary computer today).
RevK 
@revk Oops, yes, silly of me to have picked a number which had anything to do with binary, let alone get it wrong for many cases.
But a 0..65536 type would be useful in some cases. E.g., to contain the number of bytes in a 64 kB circular buffer.
@edavies @inthehands @thephd I spent a lot of years using a computer with 16 bit address space, 65535 is stamped in my brain somehow, along with an number of other useful 16 bit decimal numbers.
penguin42@edavies @inthehands @thephd That's very difficult; a chain of multiplications gives you a rapidly increasing type size unless you've bounded everything.
@penguin42 Indeed. I doubt it happens that much in practice, though. For most real software you can easily work out what the bounds for various variables are. Automatically proving them is a bit more tricky hence @inthehands 's comment about dependent types, e.g., var i: 0..len(buffer). But it's where I think the next “Rust-like” step forward will come from. Even doing simple cases would take us a long way with most software even if some more difficult cases need a bit more manual intervention to make things really solid.
@edavies @inthehands @thephd It looks like Rust does have a (nigjtly) Ranged type:
https://docs.rs/ranged_integers/latest/ranged_integers/
I have done a bit of this type of thing in formal proving (using someone elses prover); it's often really hard to pin the range down.
https://docs.rs/ranged_integers/latest/ranged_integers/
I have done a bit of this type of thing in formal proving (using someone elses prover); it's often really hard to pin the range down.
@penguin42 @edavies @thephd
The concept you’re reaching toward here is “dependent types:” https://en.wikipedia.org/wiki/Dependent_type
In short: types can carry logical constraints, e.g. not just “integer” but “integer in a range;” not just “list of T,” but “list of T whose elements are in sorted order.” You can statically verify types like that if and only if you can show the compiler how to •prove• those logical conditions are met — and so…
@penguin42 @edavies @thephd
…you end up passing around •mathematical proofs• as part of your programming language, which are machine-generated and/or human-written + machine-verified.
It’s a grandiose, confusing dream that is either The Future of Programming™ or a quixotic research exercise, depending on who you ask.
If you’re wondering what it looks like in practice, Lean might be a place to start:
https://lean-lang.org
yoshir
victor yodaiken@thephd There have been C bignum libraries for decades - some are used a lot. But perhaps the ISO committee can find the buggiest version and make it mandatory.
mx alex tax1a - 2020 (6)@thephd alternate universe where saturating addition became the default because it more closely approximates real world behavior
pedestrian cyclist@odoruhako @thephd ours too but an alternate universe where transparent bigint support at the cpu architecture level is feasible is a much bigger alternation in the fabric of the universe; "addition actually operates in the field formed by two-to-the-word-size" is way more counterintuitive than saturation
Anna@annathyst @thephd the inevitability of that kind of thing is why we just never got into Zachtronics games
Félix@thephd this is possibly a controversial opinion, but in my view, integer overflows are _mostly_ dangerous when they cause a “second order” buffer overflow, for instance if the overflowed value is passed to malloc and you get a significantly smaller buffer than you were expecting. If we fix bounds safety, integer overflows aren’t nearly as dangerous as they are today even if we do nothing about them
Sam