>>> On NetBSD and macOS, lseek(2) on a tty succeeds: >>> if (lseek(STDIN_FILENO, 0, SEEK_CUR) == -1 )
>> Some devices are incapable of seeking. The value of the >> pointer associated with such a device is undefined. >> So I'm guessing it depends on whether you think of adding something >> to an undefined value makes sense. > Kinda feel this makes a successful return value of lseek(2) quite > unreliable: it could either mean that lseek(2) was successful, and > has updated the offset, or it could mean ":shrug: can't seek, you are > wherever you were before calling me". Well, I suspect that, as =?utf-8?B?0L3QsNCx?= suggested upthread, it _did_ update the offset, but the offset doesn't affect anything on a tty. I ran into a related case back in the day on SunOS, with 32-bit offsets: after writing 2G of data to a tape, it would abruptly start failing, apparently because the offset wrapped around and went negative. Adding an explicit lseek(,0,SEEK_SET) every once in a while cured it. Because tapes, like ttys, don't do anything with the offset, all this did was shut off the spurious error. > Wouldn't it be more helpful to the user to have lseek(2) return -1 > here? Would it? I'm not sure. What user would be helped by getting an error (and which error?) instead of success? You say Linux fails, but I don't see compatibility with Linux as enough of a Good Thing for that alone to be grounds for changing, especially since you say macOS also accepts it and thus reasonably portable code has to be prepared for either behaviour. > Since it's undefined, doing so is equally as valid (as far as the > standard is concerned). The value of the offset is undefined. That is not to say that erroring versus not erroring is undefined. (It may be, but your unqualified "it's undefined" appears to be referring back to my quote, in which case it's talking about just "the value of the [seek] pointer", not whether or not lseek itself fails.) As for standards...which standard? The only one I know of which I think is likely to say anything about this is POSIX, which as far as I can recall I don't have a copy of. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
