On Mittwoch, 3. Juni 2009, Shawn O. Pearce wrote: > We have a history of not leaving ourselves room for future expansion, > and then needing to find a backdoor in the canonical implementation > parser in order to make it work. > > In the protocol suite, its been the strlen() < pktlen trick which > has generally worked. Oh, and also sticking stuff after a fixed > length record, where we didn't care. This reminds me of one thing: upload-pack (of C git) sends a complete pack if and only if there were no errors, so that fetch-pack sees an error if upload-pack dies or if there is no side-band where upload-pack could signal an error (at least I think that are the reasons). There is a comment in upload-pack that explains a bit of it: /* Data ready; we keep the last byte to ourselves * in case we detect broken rev-list, so that we * can leave the stream corrupted. This is * unfortunate -- unpack-objects would happily * accept a valid packdata with trailing garbage, * so appending garbage after we pass all the * pack data is not good enough to signal * breakage to downstream. */ -- Hannes -- 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