From: Bruno Meneguele > Sent: 13 March 2020 11:02 > On Fri, Mar 13, 2020 at 04:34:25PM +0900, Sergey Senozhatsky wrote: > > On (20/03/12 21:35), Bruno Meneguele wrote: > > > > > > Userspace libraries, e.g. glibc's dprintf(), expect the default return value > > > for invalid seek situations: -ESPIPE, but when the IO was over /dev/kmsg the > > > current state of kernel code was returning the generic case of an -EINVAL. > > > Hence, userspace programs were not behaving as expected or documented. > > > > > > > Hmm. I don't think I see ESPIPE in documentation [0], [1], [2] > > > > [0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html > > [1] http://man7.org/linux/man-pages/man3/dprintf.3p.html > > [2] http://man7.org/linux/man-pages/man3/fprintf.3p.html > > > > -ss > > > > Ok, I poorly expressed the notion of "documentantion". The userspace > doesn't tell about returning -ESPIPE, but to the functions work properly > they watch for -ESPIPE returning from the syscall. For instance, gblic > dprintf() implementation: > > dprintf: > __vdprintf_internal: > _IO_new_file_attach: > > if (_IO_SEEKOFF (fp, (off64_t)0, _IO_seek_cur, _IOS_INPUT|_IOS_OUTPUT) > == _IO_pos_BAD && errno != ESPIPE) > return NULL; Someone explain why it is doing an explicit seek to the current position? The only reason to do that is to get the current offset. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
