always get usage() on some architectures.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. On some architectures (e.g. ARM) xar will always return the usage() text, 
even when provided with legit options.
2.
3.

What is the expected output? What do you see instead?
The command should work normally, instead you see usage text.

What version of the product are you using? On what operating system?
1.5.2 Linux ARM ubuntu.   The ARM piece is key since the code seems to work on 
x86.

Please provide any additional information below.

The fix is simple:  in main(), c should be an int rather than a char.  
getopt_long returns an int -- when it's cast to a char that can return 255 and 
not match -1, depending on the compiler and optimizer.

Original issue reported on code.google.com by poeland....@gmail.com on 3 Feb 2011 at 8:06

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Same here on powerpc (32 bit, Debian/squeeze). poeland's fix seems to work 
though:

------------------
--- src/xar.c.orig      2013-08-23 15:54:44.847974916 -0700
+++ src/xar.c   2013-08-23 16:12:08.050923063 -0700
@@ -736,7 +736,7 @@
 int main(int argc, char *argv[]) {
        int ret;
        char *filename = NULL;
-       char command = 0, c;
+       int command = 0, c;
        char **args;
        const char *tocfile = NULL;
        int arglen, i, err;
------------------

Without the patch:

$ /opt/xar.orig/bin/xar --dump-header -f test.dmg 2>&1 | head -2
Usage: /opt/xar.orig/bin/xar -[ctx][v] -f <archive> ...
        -c               Creates an archive

With the patch applied:

$ /opt/xar/bin/xar --dump-header -f test.dmg 2>&1 | head -2
magic:                  0x78617221 (OK)
size:                   28

However, now the xar dumps core when e.g. used with "-t" (list):

(gdb) run -t -f test.dmg
Starting program: /opt/xar/bin/xar -t -f test.dmg

Program received signal SIGSEGV, Segmentation fault.
0x0ffcaf78 in raw_base64_decode (
    input=0x1002d280 "MIIFXTCCBEWgAwIBAgIIOJuFhFLNiLkwDQYJKoZIhvcNAQEFBQAwgZYxCzAJBgNVBAYTAlVT\nMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBsZSBXb3JsZHdpZGUgRGV2ZWxv\ncGVyIFJlbGF0aW9uczFEMEIGA1UEAww7QXBwbGUgV29ybGR3aWRlIE"..., output=0x100361c8 "", len=1861) at lib/b64.c:81
81              x = b64revtb[input[i++]];

(gdb) bt
#0  0x0ffcaf78 in raw_base64_decode (
    input=0x1002d280 "MIIFXTCCBEWgAwIBAgIIOJuFhFLNiLkwDQYJKoZIhvcNAQEFBQAwgZYxCzAJBgNVBAYTAlVT\nMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBsZSBXb3JsZHdpZGUgRGV2ZWxv\ncGVyIFJlbGF0aW9uczFEMEIGA1UEAww7QXBwbGUgV29ybGR3aWRlIE"..., output=0x100361c8 "", len=1861) at lib/b64.c:81
#1  0x0ffcb2f4 in xar_from_base64 (
    input=0x1002d280 "MIIFXTCCBEWgAwIBAgIIOJuFhFLNiLkwDQYJKoZIhvcNAQEFBQAwgZYxCzAJBgNVBAYTAlVT\nMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBsZSBXb3JsZHdpZGUgRGV2ZWxv\ncGVyIFJlbGF0aW9uczFEMEIGA1UEAww7QXBwbGUgV29ybGR3aWRlIE"..., len=1861) at lib/b64.c:138
#2  0x0ffd4db8 in xar_signature_unserialize (x=0x10017018, reader=0x10021228) 
at lib/signature.c:322
#3  0x0ffca8c0 in xar_unserialize (x=0x10017018) at lib/archive.c:1476
#4  0x0ffc7208 in xar_open (file=0xbffffdbc "test.dmg", flags=0) at 
lib/archive.c:283
#5  0x1000273c in list (filename=0xbffffdbc "test.dmg", arglen=0, 
args=0x10017008) at src/xar.c:521
#6  0x100042c8 in main (argc=4, argv=0xbffffc34) at src/xar.c:1041

However, this may warrant for another bug.

Linux 3.11-rc5 (powerpc)
gcc (Debian 4.7.2-5) 4.7.2
GNU ld (GNU Binutils for Debian) 2.22

Original comment by ckujau on 23 Aug 2013 at 11:27