string length() does not give iterable item count

[carlobaldassi]

This works:

julia> ["xyz"...]
3-element Char Array:
 'x'
 'y'
 'z'

This segfaults:

julia> ["é"...]
Segmentation fault (core dumped)

My guess is that [x...] should use strlen instead of length in this case.

[staticfloat]

gdb backtrace:

julia> ["é"...]

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00000001000498a0 in jl_method_table_assoc_exact ()
(gdb) bt
#0  0x00000001000498a0 in jl_method_table_assoc_exact ()
#1  0x0000000100049b9a in jl_apply_generic ()
#2  0x000000010004e66e in jl_f_apply ()
#3  0x000000010007fb14 in do_call ()
#4  0x000000010007eaa9 in eval ()
#5  0x000000010008a004 in jl_toplevel_eval_flex ()
#6  0x000000010004e8f7 in jl_f_top_eval ()
#7  0x0000000101d5aded in ?? ()
#8  0x0000000100049c65 in jl_apply_generic ()
#9  0x0000000101d13d92 in ?? ()
#10 0x0000000101d13a2c in ?? ()
#11 0x0000000100049c65 in jl_apply_generic ()
#12 0x00000001000017be in true_main ()
#13 0x00000001000839c3 in julia_trampoline ()
#14 0x0000000100001b7b in main ()
(gdb) 

[carlobaldassi]

I'll add that comprehensions get the length wrong but don't segfault:

julia> [x for x in "ẍÿƶ"]
7-element Any Array:
 'ẍ'   
 'ÿ'   
 'ƶ'   
 #undef
 #undef
 #undef
 #undef

I wonder if it's reasonable to define an iteration_length or iterlen function which defaults to length in general, strlen for strings, and possibly x->nothing (or something similar) for iterators for which the number of iterations can't be known in advance (so that things like comprehensions and [x...] can use dynamically growing memory).

[JeffBezanson]

This is probably one reason we used to have a separate numel. @StefanKarpinski what do you think?

[JeffBezanson]

BTW, the segfault is also due only to length giving the wrong value for this case.

[StefanKarpinski]

Ho-hum. I'm not really sure what to do here. Didn't you want to rename strlen anyway?

[JeffBezanson]

The only use of length for strings seems to be in done for strings. If one always called done instead of doing i > length(s), perhaps length could return the number of characters.

[StefanKarpinski]

I have to think about this because it radically changes what was a pretty well-thought-through, coherent view of strings – i.e. that 1:length(s) is the range of indices but there's not a character for every index. Also, keep in mind that any use of end to index into a string is implicitly also a call to length(s). However, unless you wrap it in thisind, chances are that usage is broken. I think this may need a bit of a revamp...

[JeffBezanson]

If we could fix both those things it would be fantastic. Otherwise, we could just bring back numel as the same as length for everything but strings.

[StefanKarpinski]

Hmm. This is a tricky problem.

[vtjnash]

@JeffBezanson isn't this fixed? (with extensions to comprehensions covered by open issue #1457 referenced above)

[JeffBezanson]

Not entirely, since the title of this issue is still true afaik. Either
length or some other function should reliably give an item count for
collections where it makes sense. Or there could be a separate function to
give the last valid index.
On Nov 8, 2012 1:47 AM, "Jameson Nash" notifications@github.com wrote:

@JeffBezanson https://github.com/JeffBezanson isn't this fixed? (with
extensions to comprehensions covered by open issue #1457https://github.com/JuliaLang/julia/issues/1457referenced above)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1454#issuecomment-10178237.

[JeffBezanson]

See #1939.