From: Junio C Hamano Date: Fri, 06 Apr 2007 00:29:29 GMT Subject: Re: [PATCH 02/13] declare overflow during base128 decoding when 1 MSB nonzero, not 7 Message-ID: <7vvegal506.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <56b7f5510704051608g4bf9ffb7t9f94b532c7a0ebdf@mail.gmail.com> "Dana How" writes: > Concerning SEEK_SET, > you are correct: my unistd.h #define's SEEK_SET to 0. My understanding of the history is back when there was seek() but not lseek() nor SEEK_X macros, everybody passed bare integers and it was quite well established that 0 meant what SEEK_SET means now, so I would be quite surprised if there is _any_ platform that defines SEEK_SET to anything but zero. Having said that, I wonder if this kind of thing can be caught with sparse. We should be able to express (or perhaps sparse could have a built-in rule that says) something like "although the standard says the third parameter to lseek() can be any integer, you should not use anything but SEEK_X preprocessor macros; also SEEK_X preprocessor macros, although they are typically just "#define"s of small integer literals, can never appear anywhere other than the third parameter as seek() and lseek()". I realize that there needs some data-flow analysis to allow a code like this, though: int move_to(int fd, ofs_t offset, int relative) { int whence = SEEK_SET; if (relative) { whence = SEEK_CUR; offset += relative; } return lseek(fd, offset, whence) != (off_t)-1; } > But if someone edits this, the arg order might remain. Very true, and that is why I said I am going to take the patch.