On Wed, Apr 26, 2000 at 12:25:08PM +0100, John Holdsworth wrote: > > > Included is a bug fix to the decode of unpack 'N/Z*' which > > > was not adding a byte to the encoded length as pack does. > > Not clear. unpack 'N/Z*' with N unpacking to 14 should be the same as > > Z14. Is it? > > It seems not. There is some rather strange code in pp_pack() Hmm, I was asking about unpack(), not about pack(). > case 'A': > case 'Z': > case 'a': > fromstr = NEXTFROM; > aptr = SvPV(fromstr, fromlen); > if (pat[-1] == '*') { > len = fromlen; > if (datumtype == 'Z') > ++len; > } > which bumps the length. ???? This chunk calculates the *required* length basing on the length of the input data. The calculatation looks correct. AFAICU, It should have nothing to do with unpack() logic. What is the problem you want to address? > > > There is also option to use 'N/a*4' to round the length of encoded > > > strings to four bytes as required by SUN XDR RFC 1832. > > > > I think a more general command is needed. Say, 'x!8' which would add > > 0-bytes until the next position which is multiple of 8. Then you > > would write 'N/a*x!4'. > > I would agree with this. I was trying to make the absolute > minum change possible to what is very much core code. Thanks, but for user-visible changes this is not the best criterion. > > > my @arr = (1,2,3,4); > > > my $packed = pack "N/N?N/N?", scalar @arr, @arr, scalar @arr, @arr; > > > > Again, something more general is needed. Something like > > > > my $packed = pack "(N//N)(N//N)", scalar @arr, @arr, scalar @arr, @arr; > I'm not so sure this would be more intuitive. '?' is in effect a new way to specify > the length of operands after '123' and '*'. Currently this can be done with interpolation into the pattern: my $len = @arr; my $packed = pack "N$len N$len", @arr, @arr; I can easily believe that the feature you wanted to add is desirable, but until we can invent a more intuitive and more general "API". I do not think that what you did should go in. IlyaThread Previous | Thread Next