On Thu, Feb 05, 2015 at 04:28:47PM -0500, Jeff King wrote: > On Thu, Feb 05, 2015 at 01:16:36PM -0800, Junio C Hamano wrote: > > > Jeff King <p...@peff.net> writes: > > > > > On Thu, Feb 05, 2015 at 01:53:27AM -0500, Jeff King wrote: > > > > > >> I also notice that config_buf_ungetc does not actually ungetc the > > >> character we give it; it just rewinds one character in the stream. This > > >> is fine, because we always feed the last-retrieved character. I dunno if > > >> it is worth fixing (it also would have fixed this infinite loop, but for > > >> the wrong reason; we would have stuck "-1" back into the stream, and > > >> retrieved it on the next fgetc rather than the same '\r' over and over). > > > > > > Here's a patch to deal with that. I'm not sure if it's worth doing or > > > not. > > > > I am not sure, either. If this were to become stdio emulator over > > random in-core data used throughout the system, perhaps. > > > > But in its current form it is tied to the implementation of config.c > > very strongly, so... > > Yeah, that was my thinking, and why I have doubts. Maybe a comment would > make more sense, like the patch below. I am also OK with just leaving > it as-is. > > -- >8 -- > Subject: [PATCH] config_buf_ungetc: document quirks in a comment
I think a comment would be fine as well. Both helps to quickly find the cause why our ungetc() might not behave as the caller expects. But I think one of both would be good so we document that this behavior is in fact intentional. Cheers Heiko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
