Another conformance question... This time fputs().

[Erik Trulsson]

On Tue, Mar 02, 2004 at 11:50:48AM -0800, Jordan K. Hubbard wrote:
> Thanks to everyone (not just bde) for reviewing the fix.  Linux was 
> right, I was wrong, EBADF it is!
> 
> On Mar 2, 2004, at 4:03 AM, Bruce Evans wrote:
> 
> >Should be EBADF, as in Linux.
> >
> >>                 return (EOF);
> >>+       }
> >
> >Otherwise, I agree with this change except for its style bugs 
> >(unsorting
> >of the #includes and tab lossage).
> 
> Change committed with #includes sorted and proper use of tabs (change 
> is consistent with the rest of the file's style).
> 
> It's also not clear to me why ENODEV is being returned, though I'm not 
> as inclined to blame isatty() since it appears to do the right thing:
> 
> #include <stdio.h>
> #include <fcntl.h>
> #include <errno.h>
> 
> main() {
>         int fd, ret;
> 
>         fd = open("/dev/null", O_RDONLY);
>         ret = isatty(fd);
>         printf("ret = %d, errno = %d\n", ret, errno);
>         close(fd);
> }
> 
> Prints:	ret = 0, errno = 25
> 
> All isatty() does is call tcgetattr(), it doesn't do an 
> ioctl(...TIOCGETA...).

But tcgetattr does call ioctl(..TIOCGETA...).

In particular isatty is implemented as
[...]
  retval = (tcgetattr(fd, &t) != -1);
[...]
  return retval;
[...]
so if isatty returns 0, then tcgetattr returned -1.
If tcgetattr returns -1 it means some error occured and errno is set to
indicate the type of error.
errno==25 is ENOTTY which is exactly what tcgetattr(3) is documented to
return if the file descriptor does not refer to a terminal (which it
does not do in this example.)
In short: The code above seems to behave absolutely correctly and as
one would expect.


Unless a function actually returns an error, (and the documentation
says it sets errno) errno should be assumed to contain garbage.
>From the intro(2) manpage:

   When a system call detects an error, it returns an integer value
   indicating failure (usually -1) and sets the variable errno
   accordingly. <This allows interpretation of the failure on receiving
   a -1 and to take action accordingly.> Successful calls never set
   errno; once set, it remains until another error occurs.  It should
   only be examined after an error.  Note that a number of system calls
   overload the meanings of these error numbers, and that the meanings
   must be interpreted according to the type and circumstances of the
   call.


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013 at student.uu.se