Thread: Does getopt() return "-1", or "EOF", at end?
I notice that in some places we compare the result of getopt(3) to
"EOF", and in some other places we compare it to "-1". I think we
should standardize on one or the other; anyone have an opinion
which it should be?
The man pages I have here (HPUX and Linux) both describe the
end-of-switches return value as being "-1". The glibc sources also
use "-1". Replacing this by EOF seems more readable but perhaps is
not strictly correct.
Are there any platforms that define EOF as something other than -1?
regards, tom lane
On Wed, 9 Jan 2002, Tom Lane wrote: > I notice that in some places we compare the result of getopt(3) to > "EOF", and in some other places we compare it to "-1". I think we > should standardize on one or the other; anyone have an opinion > which it should be? Why not standardize on -1 - considering that's what the manpages I've been able to find, say. (Linux, AIX) Using EOF where the documentation states -1 - to me, would be confusing. -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli ------------------------------------------------------------------------------- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
Tom Lane <tgl@sss.pgh.pa.us> writes: > I notice that in some places we compare the result of getopt(3) to > "EOF", and in some other places we compare it to "-1". I think we > should standardize on one or the other; anyone have an opinion > which it should be? > > The man pages I have here (HPUX and Linux) both describe the > end-of-switches return value as being "-1". The glibc sources also > use "-1". Replacing this by EOF seems more readable but perhaps is > not strictly correct. > > Are there any platforms that define EOF as something other than -1? I don't know, but the Solaris getopt() manpage specifies it as returning EOF rather than -1. I *think* POSIX mandates EOF == -1 anyhow but I'm certainly not sure of that (and we run on non-POSIX systems too I guess). -Doug -- Let us cross over the river, and rest under the shade of the trees. --T. J. Jackson, 1863
Tom Lane writes: > I notice that in some places we compare the result of getopt(3) to > "EOF", and in some other places we compare it to "-1". I think we > should standardize on one or the other; anyone have an opinion > which it should be? Definitely "-1", since getopt() comes from unistd.h and EOF is in stdio.h so EOF is not necessarily available unless the program does stream-based I/O. -- Peter Eisentraut peter_e@gmx.net
Tom Lane wrote: > I notice that in some places we compare the result of getopt(3) to > "EOF", and in some other places we compare it to "-1". I think we > should standardize on one or the other; anyone have an opinion > which it should be? > > The man pages I have here (HPUX and Linux) both describe the > end-of-switches return value as being "-1". The glibc sources also > use "-1". Replacing this by EOF seems more readable but perhaps is > not strictly correct. > > Are there any platforms that define EOF as something other than -1? I think -1 is the only way to go. EOF just doesn't seem right for a non-file access function. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Doug Royer <Doug@royer.com> writes: > Would the correct question be, "what does POSIX define?". More > and more systems (at least Unix systems) are defining POSIX > interfaces. I don't have my POSIX CD here with me or I would > quote the getopt() definition. I ~think~ it says EOF, and > the target systems include files define what EOF means. I looked at the Single Unix Specification at http://www.opengroup.org/onlinepubs/007908799/ and their man page for getopt says "-1". I believe SUS is derived from POSIX among others. If POSIX does say EOF then we might have a conflict, but otherwise the tide seems to be running to -1. regards, tom lane
Tom Lane wrote: > > I notice that in some places we compare the result of getopt(3) to > "EOF", and in some other places we compare it to "-1". I think we > should standardize on one or the other; anyone have an opinion > which it should be? > > The man pages I have here (HPUX and Linux) both describe the > end-of-switches return value as being "-1". The glibc sources also > use "-1". Replacing this by EOF seems more readable but perhaps is > not strictly correct. > > Are there any platforms that define EOF as something other than -1? Would the correct question be, "what does POSIX define?". More and more systems (at least Unix systems) are defining POSIX interfaces. I don't have my POSIX CD here with me or I would quote the getopt() definition. I ~think~ it says EOF, and the target systems include files define what EOF means.
Attachment
On Wed, Jan 09, 2002 at 12:58:45PM -0500, Tom Lane wrote: > I notice that in some places we compare the result of getopt(3) to > "EOF", and in some other places we compare it to "-1". I think we > should standardize on one or the other; anyone have an opinion > which it should be? > > The man pages I have here (HPUX and Linux) both describe the > end-of-switches return value as being "-1". The glibc sources also > use "-1". Replacing this by EOF seems more readable but perhaps is > not strictly correct. > > Are there any platforms that define EOF as something other than -1? OpenBSD's getopt(3): The getopt() function was once specified to return EOF instead of -1. This was changed by IEEEStd1003.2-1992 (``POSIX.2'') to decouple getopt() from <stdio.h>. -- David Terrell | "If NNTP had a protocol extension for dbt@meat.net | administering a spanking (long overdue if Nebcorp Prime Minister | you ask me), you'd be yelping right now." http://wwn.nebcorp.com/ | - Miguel Cruz
Tom Lane wrote: > > Doug Royer <Doug@royer.com> writes: > > Would the correct question be, "what does POSIX define?". More > > and more systems (at least Unix systems) are defining POSIX > > interfaces. I don't have my POSIX CD here with me or I would > > quote the getopt() definition. I ~think~ it says EOF, and > > the target systems include files define what EOF means. > > I looked at the Single Unix Specification at > http://www.opengroup.org/onlinepubs/007908799/ > and their man page for getopt says "-1". > I believe SUS is derived from POSIX among others. > If POSIX does say EOF then we might have a conflict, > but otherwise the tide seems to be running to -1. It's probabily the same. Tom Lane wrote: > > Doug Royer <Doug@royer.com> writes: > > And if the default for int or char is unsigned as it can > > be on some systems, the code does exactly that. > > There are no systems where "int" means "unsigned int". That would break > (to a first approximation) every C program in existence, as well as > violate the ANSI C specification. Your right - oops.
Attachment
David Terrell <dbt@meat.net> writes:
> OpenBSD's getopt(3):
> The getopt() function was once specified to return EOF instead of -1.
> This was changed by IEEE Std1003.2-1992 (``POSIX.2'') to decouple
> getopt() from <stdio.h>.
Ah, nothing like historical perspective to make it all clear. Thanks.
Looks like -1 it shall be.
regards, tom lane
On Wed, 9 Jan 2002 16:10:15 -0500 (EST) Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Tom Lane wrote: > > I notice that in some places we compare the result of getopt(3) to > > "EOF", and in some other places we compare it to "-1". I think we > > should standardize on one or the other; anyone have an opinion > > which it should be? > > > > The man pages I have here (HPUX and Linux) both describe the > > end-of-switches return value as being "-1". The glibc sources also > > use "-1". Replacing this by EOF seems more readable but perhaps is > > not strictly correct. > > > > Are there any platforms that define EOF as something other than -1? > > I think -1 is the only way to go. EOF just doesn't seem right for a > non-file access function. FWIW, here's a quote from the FreeBSD man page: The getopt() function was once specified to return EOF instead of -1. This was changed by IEEE Std 1003.2-1992 (``POSIX.2'')to decouple getopt() from <stdio.h>. -- Richard Kuhns rjk@grauel.com PO Box 6249 Tel: (765)477-6000 \ 100 Sawmill Road x319 Lafayette, IN 47903 (800)489-4891 /