Thread (42 messages) flat view 42 messages, 3 authors, 2018-07-16

Re: [PATCH v2 6/9] gpg-interface: do not hardcode the key string len anymore

From: Henning Schild <hidden>
Date: 2018-07-11 13:46:42

Am Wed, 11 Jul 2018 08:34:25 -0400
schrieb Jeff King [off-list ref]:
On Wed, Jul 11, 2018 at 10:54:59AM +0200, Henning Schild wrote:
quoted
quoted
In the general case you need:

  found = *next ? next + 1 : next;

or similar. In this case, you can actually do:

  found = next;

because we know that it's OK to search over the literal space
again. But that's pretty subtle, so we're probably better off
just doing the conditional above.

(And yes, looking at the existing code, I think it's even worse,
as there does not seem to be a guarantee that we even have 16
characters in the string).  
The existing code works only on expected output and the same is true
for the version after this patch. Making the parser robust against
random input would imho be a sort of cleanup patch on top of my
series. .. or before, in which case i would become responsible for
making sure that still works after my modification.
This argument is twofold. I do not really want to fix that as well
and it might be a good idea to separate concerns anyways.  
I think it's worth addressing in the near term, if only because this
kind of off-by-one is quite subtle, and I don't want to forget to deal
with it. Whether that happens as part of this patch, or as a cleanup
before or after, I'm not picky. :)
I get that and if anyone is willing to write that code, i will base my
patches on it. What i want to avoid is taking responsibility for
problems i did not introduce, just because i happen to work on that
code at the moment. Keeping track of that (not forgetting) is also not
for the random contributor like myself.

Henning
-Peff
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help