Mail Archives: djgpp/1999/02/01/22:36:21
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.
- Raw text -