Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!romp!auschs!awdprime!toysrus!dcm
From: dcm@toysrus.uucp (dcm)
Newsgroups: comp.unix.aix
Subject: Re: getopt (3) problem?
Message-ID: <3492@awdprime.UUCP>
Date: 13 Sep 90 16:20:48 GMT
References: <1990Sep12.011152.26067@maverick.ksu.ksu.edu> <3452@aix.aix.kingston.ibm.com>
Sender: news@awdprime.UUCP
Reply-To: dcm@reed.UUCP (dcm)
Organization: IBM AWD, Austin, TX
Lines: 27

In article <3452@aix.aix.kingston.ibm.com> bchristy@aix.aix.kingston.ibm.com (JB Christy) writes:
>
>I was bitten by something similar, and I believe the problem is that EOF is
>#define'd as -1, which is an int, and I bet you've declared c as char.  When
>the comparison occurs, c is promoted to an int but the sign is lost, so it
>becomes 255 instead of -1.  Try casting EOF to a char, e.g.
>
>	while(( c = getopt( argc, argv, "d:m" )) != (char) EOF ) {
>
>That way -1 gets "demoted" to a char and all is well.


	No no no.  This works, but is not correct.  The solution is
	to note that getopt returns "int", and declare "c" as "int".
	"(char) EOF" is wrong.  I'm not even sure it's portable.

	This is the same problem that K&R #1 noted:  when comparing
	against EOF, *always* use an int var, not a char.

	Back to the basics.  Signed char vs unsigned char.  (found
	the same bug in "more".  Did BSD really write it that way?)
--------
	Craig Miller, contractor @ IBM AWD, Austin  (I don't speak for IBM)
	UUCP: ..!uunet!cs.utexas.edu!ibmaus!auschs!toysrus.austin.ibm.com!dcm

	"Just because it works doesn't means it's right, stupid!"
	"Don't believe .signature files."