proot@ksuvax1.cis.ksu.edu (Paul T. Root) (09/12/90)
In compiling and running some things, I have found that getopt doesn't act
right. When it runs out of parameters instead of returning an EOF it returns
a -1.
I have called my Rep and he said he'd pass it along.
I've used getopt quite a bit on Suns, Vax, PS/2's, 370's, so I don't think
its operator error.
The work around I use is like this:
while(( c = getopt( argc, argv, "d:m" )), c != EOF && c != -1 ) {
switch( c ) {
.
.
.
}
}
Keeping the world informed...
Paul.bchristy@aix.aix.kingston.ibm.com (JB Christy) (09/12/90)
In article <1990Sep12.011152.26067@maverick.ksu.ksu.edu> proot@ksuvax1.cis.ksu.edu (Paul T. Root) writes: }In compiling and running some things, I have found that getopt doesn't act }right. When it runs out of parameters instead of returning an EOF it returns }a -1. }[...] }The work around I use is like this: } while(( c = getopt( argc, argv, "d:m" )), c != EOF && c != -1 ) { 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. =-=-=-=-= Disclaimer: I don't even work for IBM; I certainly don't speak for them. -- JB (bchristy@aix, x0563, 5NC-01) Resource One, Inc. "She was a suicide blonde - dyed by (Sub-contractor at IBM Kingston) her own hand." --Rita Mae Brown
guy@auspex.auspex.com (Guy Harris) (09/13/90)
>In compiling and running some things, I have found that getopt doesn't act >right. When it runs out of parameters instead of returning an EOF it returns >a -1. You mean EOF *isn't* -1 on whatever kind of system you're using? (It's presumably some flavor of AIX system; since you say it works OK on PS/2s and 370's, if you mean it works OK on those systems under AIX, I assume the system in question is an RT or RS6000.) EOF is #defined as -1 in all the UNIX systems with which I'm familiar.
richard@locus.com (Richard M. Mathews) (09/13/90)
bchristy@aix.aix.kingston.ibm.com (JB Christy) writes: >In article <1990Sep12.011152.26067@maverick.ksu.ksu.edu> proot@ksuvax1.cis.ksu.edu (Paul T. Root) writes: >}The work around I use is like this: >} while(( c = getopt( argc, argv, "d:m" )), c != EOF && c != -1 ) { This workaround makes no sense. EOF is defined as -1 on AIX/370, AIX PS/2, and AIX RT. Our 6000s are being moved right now, but I strongly suspect EOF is -1 there too (I did check a very old copy of 6000 sources and it was defined as -1 there). >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! Right idea but the answer is backwards. It mostly works, but it's wrong. Look at the man page. Getopt is defined as returning an int. The example shows "c" being declared as an int. The correct fix is to declare "c" correctly, not to hack the code to make EOF have the same incorrect type as the variable. What would happen if the character returned by getopt was 0xff? A char simply can't hold each of the possible character values and the "all done" flag, too. Richard M. Mathews Locus Computing Corporation richard@locus.com lcc!richard@seas.ucla.edu ...!{uunet|ucla-se|turnkey}!lcc!richard
proot@ksuvax1 (Paul T. Root) (09/13/90)
In article <1990Sep12.011152.26067@maverick.ksu.ksu.edu> proot@ksuvax1.cis.ksu.edu (Paul T. Root) writes: >I've used getopt quite a bit on Suns, Vax, PS/2's, 370's, so I don't think >its operator error. But then again it probably is. I didn't think that to see what EOF was (I had been thinking that it was 0). Oh, well. What it comes down to is that c in the example below is a character instead of an integer. And (char) -1 != (int) -1. I would have expected a casting error (after all of the (int)NULL's I've done in AIX. > >The work around I use is like this: > > while(( c = getopt( argc, argv, "d:m" )), c != EOF && c != -1 ) { > switch( c ) { > . > . > . > } > } > Oh well, all's well with the Rios now. Is anybody working on GNU emacs with X-Windows now? I think that's the next project. Paul.
shh@i88.isc.com (Shiv Haris) (09/13/90)
In article <1990Sep12.011152.26067@maverick.ksu.ksu.edu> proot@ksuvax1.cis.ksu.edu (Paul T. Root) writes: >In compiling and running some things, I have found that getopt doesn't act >right. When it runs out of parameters instead of returning an EOF it returns >a -1. > >I have called my Rep and he said he'd pass it along. > > >The work around I use is like this: > > while(( c = getopt( argc, argv, "d:m" )), c != EOF && c != -1 ) { > switch( c ) { > . > } > } > >Keeping the world informed... >Paul. Take a quick look to see if your machine has type "char" to be unsigned. if so then if you do a compare of (c != EOF) and c is 0xff and EOF is -1, will be false. Hence you problem. The fix should really be: while(( c = getopt( argc, argv, "d:m" )) != 0xff) { } Hope this helps, -Shiv
dcm@toysrus.uucp (dcm) (09/13/90)
In article <4053@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>In compiling and running some things, I have found that getopt doesn't act >>right. When it runs out of parameters instead of returning an EOF it returns >>a -1. > >You mean EOF *isn't* -1 on whatever kind of system you're using? (It's *Of course* EOF is -1 on Aix. We didn't mess with that! -------- 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."
dcm@toysrus.uucp (dcm) (09/13/90)
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."
guy@auspex.auspex.com (Guy Harris) (09/15/90)
>But then again it probably is. I didn't think that to see what EOF was (I >had been thinking that it was 0). Oh, well. What it comes down to is that >c in the example below is a character instead of an integer. And >(char) -1 != (int) -1. I would have expected a casting error (after all >of the (int)NULL's I've done in AIX. OK, now I'm curious how the workaround: >>The work around I use is like this: >> >> while(( c = getopt( argc, argv, "d:m" )), c != EOF && c != -1 ) { worked, since EOF is -1 on the RIOS, and comparing "c" twice against -1 shouldn't yield any results different from doing it once....