Date: Mon, 1 Feb 1999 22:34:55 -0500 Message-Id: <199902020334.WAA06724@envy.delorie.com> From: DJ Delorie To: djgpp AT delorie DOT com In-reply-to: <3.0.6.32.19990201215716.008b0840@pop.netaddress.com> (message from Paul Derbyshire on Mon, 01 Feb 1999 21:57:16 -0500) Subject: Re: Clarification of some errno values. References: <3 DOT 0 DOT 6 DOT 32 DOT 19990201215716 DOT 008b0840 AT pop DOT netaddress DOT com> Reply-To: djgpp AT delorie DOT com I actually had to look some of these up. Check the djgpp libc sources to see which are actually used by djgpp. Some are included only to satisfy ANSI or POSIX compatibility but aren't actually used by DJGPP. > E2BIG 'Argument list too long' -- is this to do with > varargs? No, with system(), spawn(), etc. There's a limit to how many arguments you can pass to other programs (limited by the transfer buffer size, command line length, etc). > ECHILD 'No child processes' -- What the heck? Pipe > related? calling wait() when there's nothing to wait for. Not much sense under DJGPP, but it's there for compatibility. > EFAULT 'Bad address' -- Not a memory address, > which causes SIGSEGV... > raw disk address? This is for when a libc function can tell it's a bogus address without actually using it (like NULL or -1), rather than just segfaulting inside libc. > EFBIG 'File too large' -- File too large??? Writing to a file that's already 2G. DOS can't handle files bigger than that. > EINTR 'Interrupted system call' -- ??? Hit Ctrl-C during, say, seek(). If there's a signal handler and it returns, this is the error code returned by the interrupted function. > EISDIR 'Is a directory' -- file opening related? Yup. Can't open() a directory. > EMLINK 'Too many links' -- ??? MSDOS doesn't support real symbolic links, but the OS normally limits the number of times it will traverse symlinks before it decides it's in an infinite loop. > ENFILE 'Too many open files in system' > -- How is this distinct > from EMFILE? EMFILE means that a single actual file (inode) has too may directory entries (links) that refer to it. Look up "ln" (the non-symbolic link) on any unix system. DJGPP doesn't have this problem. ENFILE means you called open() too many times. > ENOLCK 'No locks available' -- Where does this come > from? flock() and/or lockf() > ENOMEM 'Not enough memory' -- Does malloc() do this > when it returns 0? No, but sbrk() might, or exec*() on unix. If malloc() returns it, it's only because sbrk() returned it. > ENOSYS 'Function not implemented' -- ??? Like fork(), which exists for compatibility, but always returns an error because DJGPP isn't able to do that. > ENOTDIR 'Not a directory' -- Trying to treat a file > as a directory? opendir() on a regular file. > ENOTEMPTY 'Directory not empty' -- Does it only let you > rmdir an empty dir? Yes. > ENOTTY 'Inappropriate I/O control operation' > -- ??? (seek() on PRN:?) Yes, and some termios functions (like setting the Ctrl-C key) require that you use a tty. Any ioctl() might also return this if the request is bogus. > ENXIO 'No such device or access' -- How is this distinct > from ENODEV? ENODEV is for an inappropriate access to an existing device, like reading from a printer. ENXIO is for trying to access a device the system knows about, but which is physically not present, like an empty tape drive. > ESPIPE 'Invalid seek' -- seek() on a pipe? Yup. Probably on ttys too. > ESRCH 'No such process' -- ??? kill(). Not much use in DJGPP. > EXDEV 'Improper link' -- ??? Like renaming a file to a directory on another drive. > ENMFILE 'No more files' -- ??? (related to the dir > operations that fetch > filenames > sequentially?) readdir() returns this when it's at the end of a directory scan, as opposed to stopping due to some actual error condition. > 2. Is every last one of these macros ANSI standard and dependable? > If not, which macros may only exist on some platforms? Most are ANSI or POSIX. The DJGPP header files tell you which are which, but you can use #ifdef to test for each anyway.