On Mon, 19 May 2008 10:15:26 +0100, Tim Bunce <Tim.Bunce@[...].com>  wrote:
>  
>  On Fri, May 16, 2008 at 01:45:51AM +0100, Rudolf Lippan wrote:
> > On Thu, 15 May 2008 13:21:34 +0100, Tim Bunce <Tim.Bunce@[...].com>
>  wrote:
> > > It would be good to add a clear comment somewhere that the pointers in
> > > the keys array are only valid until perl next free mortal temps.
> > > (There are faster ways of doing that but the use case for the numeric
> > > keys isn't speed critical.)
> > >
> > Suck as, if you don't mind me asking?
>  
>  ("Such as", I presume :)
>  

Yes!  Good thing I did not double bounce on the 's' or it could have been
rather confusing.

>  Or, more deeply, instead of sorting an array of int's you could sort an
>  array of { int key_as_int, char *ptr_to_key } structs. That way you'd
>  also avoid the potential risk of problems with keys like "01" or "1.0"
>  that change when converted to int and back to a string.
>  

That was my first thought, but I gave up on in when I realised that I 
would have to figure a place to put the typedef 

I changed the code to use a struct (although I just threw the declaration
in ).
It makes it cleaner and gets rid of the sv_2mortal'd copy of the keys.


> > >>
 
>  Whatever seems reasonable (and best for ShowErrorStatement usage).
>  
I went and had the wrapper unSVify the params and call _join_hash_sorted().
This
way there is no need to create a bunch of SVs that get thrown away.


-r