Revision 5e0be134d35a31f41921f89331a95337bb38c152 authored by Jeff King on 05 February 2015, 06:53:28 UTC, committed by Junio C Hamano on 05 February 2015, 20:37:36 UTC
When we are parsing a config value, if we see a carriage return, we fgetc the next character to see if it is a line feed (in which case we silently drop the CR). If it isn't, we then ungetc the character, and take the literal CR. But we never check whether we in fact got a character at all. If the config file ends in CR, we will get EOF here, and try to ungetc EOF. This works OK for a real stdio stream. The ungetc returns an error, and the next fgetc will then return EOF again. However, our custom buffer-based stream is not so fortunate. It happily rewinds the position of the stream by one character, ignoring the fact that we fed it EOF. The next fgetc call returns the final CR again, over and over, and we end up in an infinite loop. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
1 parent 282616c
| File | Mode | Size |
|---|---|---|
| araxis | -rw-r--r-- | 392 bytes |
| bc3 | -rw-r--r-- | 401 bytes |
| codecompare | -rw-r--r-- | 387 bytes |
| deltawalker | -rw-r--r-- | 628 bytes |
| diffmerge | -rw-r--r-- | 286 bytes |
| diffuse | -rw-r--r-- | 282 bytes |
| ecmerge | -rw-r--r-- | 340 bytes |
| emerge | -rw-r--r-- | 415 bytes |
| gvimdiff | -rw-r--r-- | 29 bytes |
| gvimdiff2 | -rw-r--r-- | 29 bytes |
| kdiff3 | -rw-r--r-- | 499 bytes |
| kompare | -rw-r--r-- | 83 bytes |
| meld | -rw-r--r-- | 680 bytes |
| opendiff | -rw-r--r-- | 301 bytes |
| p4merge | -rw-r--r-- | 651 bytes |
| tkdiff | -rw-r--r-- | 224 bytes |
| tortoisemerge | -rw-r--r-- | 638 bytes |
| vimdiff | -rw-r--r-- | 625 bytes |
| vimdiff2 | -rw-r--r-- | 29 bytes |
| xxdiff | -rw-r--r-- | 618 bytes |
Computing file changes ...
