[RFC] zero length FxA behaviour #468

plobsing opened this Issue Jan 29, 2010 · 4 comments

5 participants


FixedBooleanArray, FixedStringArray, FixedIntegerArray, and FixedFloatArray do not allow specifying a length of 0, giving a misleading error of "Fixed${type}Array: can't resize".

FixedPMCArray ignores being set to zero length, remaining uninitialized.

Allowing for zero lengthed arrays allows code that handles "0 or more elements" cases to avoid checking against the zero case. For example:

.sub 'fixed_ints_upto'
    .param int i
    .local pmc retv
    retv = new ['FixedIntegerArray']
    retv = i
    $I0 = 0
         if $I0 >= i goto end_loop:
         retv[$I0] = $I0
         inc $I0
         goto loop

    .return (retv)

This will currently fail. To avoid failures, we would have to check for a zero valued argument and handle that case separately.

Zero is a valid length for an array, so I propose that we allow FxAs to be set to zero length (and not be subsequently resizable).

Alternatively, the behaviour could be to ignore setting the length to zero (as is done now in FPA). However, this can be seen as violating the set once property of FxA length.

Originally http://trac.parrot.org/parrot/ticket/1421

Parrot Virtual Machine member


I would like to reject this RFC. We have .init_int now and example can be rewritten as retv = new ['FixedIntegerArray'], i which DTRT. If some of *Arrays doesn't support it we should just fix them.

-- Bacek.


The point about this isn't that size is set separately, it's that zero should be treated as a valid length, and not as a sentinel for "not set yet".

As it stands, setting the length of an FxA to zero has insufficent effect, whether you do it by passing the length to the constructor, or by setting it afterwards.

We shouldn't just do nothing; if zero-length is deemed invalid, then setting it should throw an exception rather than silently ignore the change.


How about assigning some hard-coded non-pointer value (call it FxA_UNINITIALIZED) to the pointer used for storing the array's values until it's initialized? The F*A code would need some updates to check for FxA_UNINITIALIZED instead of looking at the size, but that should provide a reasonable solution.


I like that idea.

But the main point, implementation details apart, is to decide if we want to change the current behavior, and in that case add a deprecation notice and document the new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment