brenhinkeller / StaticTools.jl

Enabling StaticCompiler.jl-based compilation of (some) Julia code to standalone native binaries by avoiding GC allocations and llvmcall-ing all the things!
MIT License
167 stars 12 forks source link

Toobigarrays #23

Closed brenhinkeller closed 2 years ago

brenhinkeller commented 2 years ago

One possible approach to dealing relatively consistently with #22

mkitti commented 2 years ago

This makes some assumptions that Int == Int64. Instead of hardcoding Int128 use

julia> widen(Int)
Int128
brenhinkeller commented 2 years ago

Should also work for Int==Int32 no?

brenhinkeller commented 2 years ago

Though I guess we might be wasting cycles if we're using Int128 when we could be using Int64 :)

mkitti commented 2 years ago

Who knows? Maybe we'll be running on 256-bit computers in the future.

brenhinkeller commented 2 years ago

Ok, we'll try the Base.Checked.mul_with_overflow approach for now. I'm not thrilled with the extra cycles for what's effectively an academic case at present, so may revisit in the future, but it's nice to be future-proof for when we all have exabytes of memory.

mkitti commented 2 years ago

I'm not thrilled with the extra cycles for what's effectively an academic case at present, so may revisit in the future, but it's nice to be future-proof for when we all have exabytes of memory.

With this package, we've gotten ourselves into playing the role of libc. The last thing we want is for this to be a buffer overflow attack vector. Plus it would be good to protect against accidental segmentation faults.

https://seclists.org/bugtraq/2002/Aug/91

There may be more efficient methods of handling this. If efficiency is needed though, it is quite easy to work around this high level check.

brenhinkeller commented 2 years ago

Hah, this is true. I suppose someone could actually use this to make software used by people other than the developer someday 😅