Re: [PATCH] config: do not ungetc EOF

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]