(no subject)

[theducks]

Dear LazyGDB..

Not knowing much about C, I find myself confused by the following, extrapolated from some code I didn't write:

Code:

#include <stdlib.h>
#include <signal.h>

int main(int argc, char **argv)
{

        char    opt;
        char    *options = "a:de:f:l:p:";

        opt = getopt(argc, argv, options);
        printf ("Opt: %d\n",opt);

}

Linux on PowerPC:

suffix:~# ./test -a fish
Opt: 97
suffix:~# ./test
Opt: 255

Linux on i686:

vitalstatistix:~# ./test -a fish
Opt: 97
vitalstatistix:~# ./test 
Opt: -1

What is the deal?

Comments

[girlmitzi.livejournal.com]

I don't know what this means either but for some reason I just took off all my clothes...

[dannipenguin.livejournal.com]

You're seeing the difference between a signed char and an unsigned char (why does C say char can have a sign? who knows). Bitwise, they are the same value: http://en.wikipedia.org/wiki/Two%27s_complement

It's worth noting that man 3 getopt (first point of call) tells you that -1 is returned when there are no more options to pass and that getopt() returns an 'int', not a 'char'.

[luyer.livejournal.com]

Firstly, %d is the format option for an int. You should be using %hhd or %hhu for a char (d being signed, u unsigned). Or typecasting opt to (int)opt.

Secondly, you should be using an int anyway: getopt returns int. You didn't #include unistd.h, so you may be implicitly defining getopt, and implicitly defining it to return char.

Thirdly, PowerPC vs i686: different byteorder. This may impact the result of either of these errors.

Fourthly, -1 is the unsigned char with the same binary representation as the signed char 255.

Finally: This code depends on undefined behavior. C can do absolutely anything where the standard does not define the behavior, and due to the highly optimized nature of most C code, often does something you don't expect.