Seb,
Yes, I can reproduce this issue.
{ 1, 0 }
{ 1, 1 }
returns 0, when it should return -1.
Interestingly, if you use:
{ 1, 1, 1, 1, 0 } //i.e. 5 bytes
{ 1, 1, 1, 1, 1 } //i.e. 5 bytes
as the strings, it returns -1. So it clearly has a problem if the string is
exceptionally short. That got me thinking. How short?
{ 1, 1, 1, 0 } //i.e. 4 bytes, returns -1
{ 1, 1, 1, 1 }
{ 1, 1, 0 } //i.e. 3 bytes, returns -1
{ 1, 1, 1 }
{ 1, 0 } //i.e. 2 bytes, return -1
{ 1, 1 }
{ 0 } //i.e. 1 byte, returns -1 : HOLD ON, WHAT?
{ 1 }
----
So the 1-bye case succeeded, but why? The only difference between that and
the failing case was two null bytes which shouldn't even be examined.
----
{ 0, 0 } //i.e. original test case. Fails, returns 0
{ 1, 0 }
{ 1, 0, 0 } //fails, returns 0.
{ 1, 1, 0 }
{ 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 0 }
{ 1, 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 1, 0 }
{ 1, 1, 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 1, 1, 0 }
... ok ... ?
So apparently, ending with a null character that shouldn't even be examined
messes things up? Let's try something radically different:
{ 1, 1, 1, 1, 0, 0xaa } //returns -1, OK
{ 1, 1, 1, 1, 1, 0 }
{ 1, 1, 1, 1, 0, 0 } //returns -1, OK
{ 1, 1, 1, 1, 1, 0xaa }
{ 1, 1, 1, 1, 0, 0xaa} //returns -1, OK
{ 1, 1, 1, 1, 1, 0xbb }
On Mon, Apr 28, 2014 at 6:35 AM, Sébastien Bernard <sbern...@nerim.net>wrote:
> Le 28/04/2014 13:20, Thomas Schmitt a écrit :
>
>
>> [genisoimage]
>>> (gdb) x rpnt
>>> 0x1ea7f9: 0x00000000
>>> (gdb) x lpnt
>>> 0x1e9dc1: 0x01000000
>>> (gdb) n
>>> 659 if (strcmp(rpnt, lpnt) == 0) {
>>>
>> Both values match the prescribed names for "." and ".." in ECMA-119
>> (aka ISO 9660), 6.8.2.2 Identification of directories:
>> Single byte 0x00 is ".", single byte 0x01 is "..".
>>
> Ok, I got the bug nailed.
> Here's a sample session from my sparc:
> ----------
> cat test_strcmp.c<<EOF
> #include <stdio.h>
> #include <stdlib.h>
>
> void main(void) {
> char stra[2];
> char strb[2];
> int result = 0;
>
> stra[0] = 0;
> stra[1] = 0;
> strb[0] = 1;
> strb[1] = 0;
>
> result = strcmp(stra,strb);
>
> printf("result from strcmp('\\0000','\\0001' is %d)\n",result);
> exit(0);
> }
> EOF
> gcc -o test_strcmp test_strcmp.c
> ./test_strcmp
> result from strcmp('\0000','\0001' is 0)
> ----------
>
> Here's the same sample from my intel workstation:
> ----------
> gcc -o test_strcmp test_strcmp.c
> ./test_strcmp
> result from strcmp('\0000','\0001' is -1)
> ----------
>
> Typicaly, an endianness error.
>
> If I apply this patch on cdrkit:
> --- genisoimage/write.c 2014-04-28 13:31:28.103571175 +0200
> +++ genisoimage/write.c.new 2014-04-28 13:31:07.255433923 +0200
> @@ -656,7 +656,7 @@
> #endif /* APPLE_HYB */
>
> /* If the entries are the same, this is an error. */
>
> - if (strcmp(rpnt, lpnt) == 0) {
> + if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {
> #ifdef USE_LIBSCHILY
> errmsgno(EX_BAD,
> "Error: '%s' and '%s' have the same ISO9660 name '%s'.\n",
>
> Then the iso is correctly generated.
>
> I'll file a bug with cdrkit. I think that genisoimage with that test is
> unable to generated any iso at all on big endian machines.
>
> So, strcmp shouldn't have yielded 0 when comparing the strings.
>>>
>> Can this be caused by alignment problems ?
>>
> Nope.
>
>
>>
>> Hum, unfortunately, valgrind is not available for sparc.
>>>
>> Then gdb will have to do.
>>
>>
>> xorriso is the one compiled from isoburn. I tried with the one from the
>>> archive, and the one rebuild from source with a debbuild.
>>> Same problem on both.
>>>
>> If you also built libisofs and libburn from source, then this burries
>> my theory of a binary incompatibility between two SPARC machines.
>>
>> I'm compiling at this moment the vanilla xorriso from gnu.
>>> Let's see what it yields.
>>>
>> It has the same source as the three library tarballs used as input
>> for Debian's xorriso. Only difference is that GNU xorriso brings
>> own copies of the library source code and links it statically with
>> the xorriso main program.
>> So it can be easily tested without interfering with installations
>> of the libraries. (And with no need for superuser privileges.)
>>
> I filed a bug with xorriso. Waiting for the number to show up.
>
>
>>
>> Have a nice day :)
>>
>> Thomas
>>
>>
>> You too ; ).
>
> Seb
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/535e3cf6.3080...@nerim.net
>
>
