On Sun, May 20, 2018 at 2:25 PM, Robert Story <rst...@freesnmp.com> wrote:
> On Sun, 20 May 2018 13:06:43 -0400 Bill wrote:
> BF> I do not think that now is the time to try to deal with any of
> BF> the fundamentals, but just not regress from previous released
> BF> behavior, and deal with the underlying issue in 5.8.1 / 5.7.4.
>
> Just to clarify, do you mean
>
> a) accepts Bart's RFV patch to fix the UTF-8 patch
>
> or
>
> b) revert the UTF-8 patch entirely an deal with the issue after a
> fuller discussion?
>
> If these are my only two options, I pick (a), since (b) results in a
regression from 5.7.1's behavior.
The original code was:
- for (x = 0; x < width && cp < ecp; x++) {
- *(*buf + *out_len) = *cp++;
- (*out_len)++;
}
- *(*buf + *out_len) = '\0';
which is not that different from the memcpy() that Bart's patch adds.
So, +1 on committing Bart's patch, because it accomplishes the goal of
fixing the regression, with the caveat that I really think that this whole
area needs to be revisited. My fundamental proposal is to use the one-pass
"is this utf8" predicate and "if so" memcpy, and "if not" use the ascii
print. This ignores for now the question of an octet string that is
truncated in the middle of a UTF-8 sequence (the "t" format says "output
all the well-formed UTF-8 sequences", and my proposal would print it as
ascii with all the "."s, but we can talk about that later. It's possible
that we could modify the "is this utf8" to say "give me the prefix that is
utf8", to fix the truncation issue.
Bill
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
