News for hackers. Stuff that matters.
Re:Ask HN: Why does validating a user require 14000 files? by KronisLV on Monday August 30, 2021 @07:37AM (#28354616)
It feels like some sort of a tree shaking solution in most of our modern development stacks is long overdue.

If only we could get rid of dynamically called code and instead could evaluate which code paths the code actually can call, then we'd be able to throw out about 90% of the contents of libraries, since most of the time noone actually uses all of that functionality.

Doing that with separate scripts is another approach, but it feels like the problem should be solved at its root.

Re:Ask HN: Why does validating a user require 14000 files? by MortenToudahl on Monday August 30, 2021 @09:12AM (#28355307)
It sounds like what's already available in C#.

https://docs.microsoft.com/en-us/dotnet/core/deploying/trimm...

Re:Ask HN: Why does validating a user require 14000 files? by yummypaint on Monday August 30, 2021 @08:07AM (#28354812)
This sounds like it could be equivalent to the halting problem
Re:Ask HN: Why does validating a user require 14000 files? by herbstein on Monday August 30, 2021 @08:12AM (#28354846)
With a conservative analysis it's possible to make an underestimation on the names one can remove. This shouldn't be done on object files but at a level where program flow information is still preserved. A flow-independent analysis using a superset lattice over the callable names should do the trick for a first-order implementation that will look good enough compared to shipping 37mb for google authentication. Further you could make it flow-sensitive for a more accurate analysis with the caveat that the runtime will be significantly longer.
Re:Ask HN: Why does validating a user require 14000 files? by jitl on Monday August 30, 2021 @09:07AM (#28355254)
Control flow graphs are well-studied, critical parts of most compilers. The halting problem involves complexity of semantics in loops and jumps, but it’s possible to understand what loops may run just fine, without being able to decide exactly when a loop may exit.

In many cases Clang and GCC compiler can easily understand loops, and even reduce them to constant time.