fatal and strange: errors when overwriting Base.<, Base.==, etc. for Int64,Float64,etc. using @eval in v0.6.0 #23605
Comments
|
Well, if you overwrite critical function incorrectly that's exactly what should happen. |
|
Not sure I agree with your claim that that is what exactly what should happen. I think you mean "we don't prevent users from overwriting critical functions; doing so may result in gibberish". Is that the approach being taken with the language in general? |
|
We tend to be permissive, but speaking in such general terms is not really useful. It would be very simple to make it an error to overwrite methods in |
|
Ok, thanks for clarifying. |
|
Here's another piece of code, this time resulting in a segfault. Is this also in the camp of "don't write stupid code"?
I guess I'm not that clear on what type of crashes are worth reporting given that the code is not supposed to work. |
|
None of overwrite base function causing crash are worth reporting. All of other segfaults/hard crashes that's not obviously using unsafe features are worth reporting and |
|
@turtleslow We always appreciate bug reports and you should always report any possible issue you run into. Different cases are different. Even if two problems have the same underlying cause that is often not obvious at first. In this case, IIUC, the original problem report did not involve a segfault, whereas your new example does. In any case we absolutely do not take the attitude that nothing is supposed to work and so bug reports are futile. That is not a terribly productive inference to make. |
|
Ok, thanks. I'll keep reporting then and you guys can ignore at your leisure if i report something that's a known philosophical issue. Let me know if you want me to open a separate issue for the segfault. |
Please do. |
|
@turtleslow, there's a notion of "type piracy" which not everyone buys into, but if you do not commit type piracy, you are definitely in the clear in the sense of "your code should not crash Julia". Type piracy is adding a method to a function that doesn't "belong" to you for arguments where none of the argument types "belong" to you. Or conversely, you are not committing an act of piracy if the function or one of the argument types belongs to you. In other words, you can be certain that what you define cannot conflict with anyone else. In this case, redefining very basic operations like integer comparison is very much type piracy: the |
Just to clarify that type piracy is a concept that is related although not a requirement for overwriting low level/ fundamental Base functions. There are other Base functions that you can overwrite for your own types that can cause low level operations involving your type to crash in a bad way. You can get this effect easily with type reflection functions, e.g. julia> struct A
b
end
julia> Base.isbits(::Type{A}) = true
julia> reinterpret(A, [1:3;])
3-element Array{A,1}:
signal (11): Segmentation fault
while loading no file, in expression starting on line 0
sig_match_simple at /build/julia-git/src/julia-avx2/src/typemap.c:125 [inlined]
jl_typemap_entry_assoc_exact at /build/julia-git/src/julia-avx2/src/typemap.c:763
jl_typemap_assoc_exact at /build/julia-git/src/julia-avx2/src/julia_internal.h:921 [inlined]There's no type piracy involved here but it's in the same class as overwriting |
Reproduces 100% of the time for me [fatal]:
This is also 100% reproducible, but you must type each line after line 2 to get the same output [strange]:
The text was updated successfully, but these errors were encountered: