Pointer types will initialise to undef and any operation on them fails: julia> a = Array(ASCIIString, 5);
julia> a[1] ERROR: access to undefined reference in getindex at array.jl:246 But you're right, for bits-types this is not an error an will just return whatever was there before. I think the reason this will stay that way is that Julia is a numerics oriented language. Thus you many wanna create a 1GB array of Float64 and then fill it with something as opposed to first fill it with zeros and then fill it with something. See: julia> @time b = Array(Float64, 10^9); elapsed time: 0.029523638 seconds (8000000144 bytes allocated) julia> @time c = zeros(Float64, 10^9); elapsed time: 0.835062841 seconds (8000000168 bytes allocated) You can argue that the time gain isn't worth the risk but I suspect that others may feel different. On Mon, 2014-11-24 at 09:28, Ronald L. Rivest <[email protected]> wrote: > I am just learning Julia... > > I was quite shocked today to learn that Julia does *not* > initialize allocated storage (e.g. to 0 or some default value). > E.g. the code > A = Array(Int64,5) > println(A[1]) > has unpredictable behavior, may disclose information from > other modules, etc. > > This is really quite unacceptable in a modern programming > language; it is as bad as not checking array reads for out-of-bounds > indices. > > Google for "uninitialized security" to find numerous instances > of security violations and unreliability problems caused by the > use of uninitialized variables, and numerous security advisories > warning of problems caused by the (perhaps inadvertent) use > of uninitialized variables. > > You can't design a programming language today under the naive > assumption that code in that language won't be used in highly > critical applications or won't be under adversarial attack. > > You can't reasonably ask all programmers to properly initialize > their allocated storage manually any more than you can ask them > to test all indices before accessing an array manually; these are > things that a high-level language should do for you. > > The default non-initialization of allocated storage is a > mis-feature that should absolutely be fixed. > > There is no efficiency argument here in favor of uninitialized storage > that can outweigh the security and reliability disadvantages... > > Cheers, > Ron Rivest
