Does getopt() return "-1", or "EOF", at end?

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

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 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, Pennsylvania 19026

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.

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 IEEE Std1003.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

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:

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.

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 /