Karl Williamson <public@khwilliamson.com> wrote: :On 6/28/22 20:27, hv@crypt.org wrote: :> Karl Williamson <public@khwilliamson.com> wrote: :> : Then the loop innards would look like: :> : :> : while (s < e) { :> : code_point = next_uvchr(s, e, &retlen); :> : :> : if (retlen < 0) { :> :> I'd recommend making this `if (retlen <= 0) {` or otherwise handling :> the retlen == 0 case, even if you only expect that when s >= e: the :> function should be capable of doing something reasonable on an empty :> string, which probably means not croaking. :> :> : ... process error ... :> : retlen = -retlen; :> : } : :It is currently illegal to call the existing functions with zero length :input. The functions don't now croak on zero length input, but they do :assert against it, which on DEBUGGING builds is pretty much the same thing. Ok, let's hope module writers habitually develop with a debug build. And in another reply: :The main difference would be that the return code doesn't have to be :disambiguated. Right now you can't tell whether the input was a NUL :character or an error, without testing each return. cpan modules don't :tend to do this, leaving them vulnerable. This API is so that you can :be naive and still be safe. How naive do you want? Anyone that fails to check for negative retlen can fail quite unsafely. I think we've established in previous discussion that you are more comfortable with this sort of overloaded interface than I am, so I do not wish to belabour the point. But this does rather remind me of https://github.com/Perl/perl5/issues/14498, where pretty much every use of grok_atou in core was buggy. I do recommend reading through that discussion again to see if there's stuff worth learning that could be applicable to this API. HugoThread Previous | Thread Next