This may be a dumb thing to do, but probably it shouldn't segfault:
julia> import Base.*; *(::Int, ::Int) = 3
Segmentation fault: 11
This issue does not occur in 0.5.1.
Version info:
Julia Version 0.6.0-pre.alpha.58
Commit 015cc63 (2017-03-06 15:15 UTC)
Platform Info:
OS: macOS (x86_64-apple-darwin16.4.0)
CPU: Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
LAPACK: libopenblas64_
LIBM: libopenlibm
LLVM: libLLVM-3.9.1 (ORCJIT, haswell)
defining 1*1 = 3
probably should segfault
This is effectively unsafe behavior (and grade A type piracy to boot). Until we have a generic mechanism for sealing certain subsets of a method table, this is going to cause segfaults.
Amusing and sarcastic responses aside, look, I'm in full agreement that no reasonable person would do this as anything but a demonstration of method dispatch. But to a user who doesn't know what "sealing subsets of a method table" means, this is valid Julia code that crashes when executed. I guess I'll assume you know why this crashes and that you know that it's not indicative of a broader problem that may affect more reasonable method definitions. To me that's not obvious, given the number of open issues with "segfault" in the title.
If you provide a mathematically correct definition for multiplication, it works just fine:
julia> mul_count = UInt(0)
0x0000000000000000
julia> import Base.*; *(a::Int, b::Int) = (global mul_count += 1; Core.Intrinsics.mul_int(a, b))
* (generic function with 178 methods)
julia> mul_count
0x00000000000000e9
julia> mul_count
0x0000000000000118
julia> mul_count
0x0000000000000147
I see, fair enough. Thanks for the explanation!
The issue is that this overwrites the same Int * Int
definition that is used everywhere in the system, and some places in the code do e.g. pointer arithmetic, or array operations that are assumed to be in bounds, and such code assumes that basic arithmetic works. We haven't deemed it worthwhile to make this code robust to incorrect Int arithmetic, at the expense of performance in the common case.
And FWIW if you are careful to not hit those code it does work
yuyichao% julia -e 'Base.:*(::Int, ::Int) = 3; println(1 * 1)'
3
The issue is ultimately that type piracy is inherently dangerous: if you redefine someone else's methods then you may be violating the assumptions their code relies upon for correctness, which can lead to various errors up to and including your program crashing. I wasn't just being funny: don't do this unless you want your program to do arbitrarily bad things. Usually a little type piracy is poor form but fairly harmless. In this case it's not.
On a related note, I don't believe type piracy is mentioned in the Julia docs. It is alluded to in some places, but perhaps deserving of its own brief discussion? Maybe under the FAQ or style guide?
Good idea. I heard the term this past year, although the concept has existed much longer.
Most helpful comment
This is effectively unsafe behavior (and grade A type piracy to boot). Until we have a generic mechanism for sealing certain subsets of a method table, this is going to cause segfaults.