David, I would prefer that an empty string can be distinguished from
an element not being set in fixed size string arrays, i.e. that
typeset -a a[100] ; [[ -v a[4] ]] || print notset prints 'notset'.
This would be in row with other languages like C, C++, java or python
where a fixed size 'set of strings' can either have strings assigned
or return a NULL pointer.

Olga

On Tue, Mar 29, 2011 at 6:24 PM, David Korn <[email protected]> wrote:
> cc: [email protected]
> Subject: Re: Re: [ast-developers] ksh: problem with arrays
> --------
>
>> >
>> > This bug was already reported and is fixed for the first bug fix release of
>> > ksh93u which will be distributed this quarter.
>> >
>> > The problem is that the declaration
>> >
>> >     typeset xx[7];
>> >
>> > is incorrectly treating xx as a fixed size array of size 7 and currently
>> > fixed sized arrays only for for fixed sized objects.  The declaration for
>> > fixed size arrays should be
>> >     typeset -a xx[7];
>> > and the declaration
>> >     typeset xx[7];
>> > is not even necessary, but should not have been treated as a fixed array.
>>
>> I'll have to answer some questions, so I'd like to confirm a few things.
>>
>> 1) It is expected that typeset xx[7]; creates array with one empty element 
>> [7] s
>> o
>> ${#xx[@]} is really expected to be 1 despite all other shells I've tested 
>> don't
>> create that
>> element, so they report zero. Old ksh reported 0 too, this changed between
>> 2008-10-01 and 2008-10-10, but I did not find anything about this in RELEASE 
>> fil
>> e.
>> This was original complain I've got so I'd like to be sure this is expected 
>> befo
>> re I tell
>> it to our users :)
>
> No, this was caused by the fixed array bug.
>        typeset xx[7]
> just creates an indexed array with at least 7 elements and none are set
> ${#xx[@]} should be 0.  This is a bug and will be fixed.
> There is no need to declare index arrays since any variable becomes
> an array when a subscript > 0 is assigned.  For large arrays
>        typeset xx[100000]
> will improve performance slightly since the array doesn't have to grow
> dynamically.
>>
>> 2) I was looking for fixed arrays at ksh man page (just searched for 'fixed' 
>> key
>> word),
>> but did not find anything. So I've looked at RELEASE file and I've found 
>> fixed a
>> rrays
>> mentioned only once (10-09-28):
>>
>> > ... It allows fixed sized indexed arrays be to defined
>> > using "typeset array[dim1][dim2]...[dimn]". ...
>>
>> so should it be typeset -a xx[7] or typeset xx[7] ?
>
> The purpose of fixed arrays was to provide a faster and more memory
> efficient array mechanism for applications that did not require
> the generality of the current array mechanism which allowed each
> element to be different.
>
> Fixed arrays were added as a compile option which is on by default but
> not document in the man page.  The reason is that it is not complete.  It
> only works for fixed size objects like integer, float, and typeset -LRZ.
> It might be completed in ksh93u.  The declaration will be
>        typeset -a array[dim1][dim2]...[dimn]
> For variable objects, there is a debate as to whether unspecifed objects
> will be initialized or not.  For example, will
>        typeset -a xx[7]
> have xx[i] unset or the empty string.  Similarly for arrays of types,
> will unset elements of type Foo_t be equivalent to Foo_t xx[i] or will
> they be unset?  I would interested in your opinions.
>>
>>
>> 3) Is there any document/web page/something about fixed arrays I could 
>> forward t
>> o users
>> who ask me about this?
> No, but this e-mail exchange is in the mailing list archives and can
> be used for further comments and exchange of ideas.
>>
>>
>> And last thing. Cosmetic issue when ksh reports problem "subscript out of 
>> range"
>> . I
>> don't care about this, it just looks odd so if there isn't any more serious 
>> bug
>> hidden:
>> $ typeset -a -i xx[7]
>> $ xx[8]=1
>> ksh: xx: subscript out of range
>> $ xx[6]=1
>> $ xx[8]=1
>> ksh: xx[6]: subscript out of range
>>
>> in first error there is "xx" in second error there is "xx[6]", always the 
>> last u
>> sed (valid)
>> index is reported in error message
>>
>>
>> >
>> > Therefore the workaround is to delete this declaration
>> > or use the declaration
>> >     typeset -a xx
>> > instead.  This is also the cause of the core dump you reported with
>> > typeset -p.
>> >
>> > Here is a patch that should fix this problem.
>>
>> Thanks, now it works the same way as prev. version and typeset -p crash is 
>> gone
>> too
>>
>
> David Korn
> [email protected]
> _______________________________________________
> ast-developers mailing list
> [email protected]
> https://mailman.research.att.com/mailman/listinfo/ast-developers
>



-- 
      ,   _                                    _   ,
     { \/`o;====-    Olga Kryzhanovska   -====;o`\/ }
.----'-/`-/     [email protected]   \-`\-'----.
 `'-..-| /       http://twitter.com/fleyta     \ |-..-'`
      /\/\     Solaris/BSD//C/C++ programmer   /\/\
      `--`                                      `--`
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers

Reply via email to