[Bug java/9532] jar -C flag is incompatible with Sun's

["jim dot balter at cw dot com" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9532



------- Additional Comments From jim.balter@cw.com  2003-06-12 22:25 -------
Subject: Re:  jar -C flag is incompatible with Sun's

On 6/12/03 2:08 PM, Jim Balter wrote:
> On 6/10/03 7:03 AM, neroden@gcc.gnu.org wrote:
> 
>> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* 
>> gcc-bugs@gcc.gnu.org.
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9532
>>
>>
>> neroden@gcc.gnu.org changed:
>>
>>            What    |Removed                     |Added
>> ---------------------------------------------------------------------------- 
>>
>>              Status|UNCONFIRMED                 |WAITING
>>
>>
>> ------- Additional Comments From neroden@gcc.gnu.org  2003-06-10 14:03 
>> -------
>>  I can't reproduce this.  The stated condition works for me (with the 
>> same version, no less.)
> 
> 
> I have no idea what "the stated condition" means.  Did you try the
> "How-To-Repeat"?
> 
>     mkdir foo
>     echo > foo/bar
>     jar cf foo.jar -C foo bar -C foo bar
> 
>     (The error message "Error adding -C to jar archive!"
>     suggests another bug).
> 
>> Can the submitter verify that this really happens?
> 
> 
> Yes.

Let me amend that -- yes and no.  On one of our Solaris boxes I get

comanche:/home/jqb/tmp$ uname -a
SunOS comanche 5.7 Generic_106541-16 sun4u sparc
comanche:/home/jqb/tmp$ /di/local/gcc-3.1.1/bin/jar --version
jar (fastjar) 0.92-gcc

Copyright 1999, 2000, 2001  Bryan Burns
Copyright 2002 Free Software Foundation
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
comanche:/home/jqb/tmp$ rm -f foo.jar; /di/local/gcc-3.1.1/bin/jar cf foo.jar -C foo bar -C foo bar
foo: No such file or directory
Error adding -C to jar archive!
comanche:/home/jqb/tmp$

On one of our Linux boxes I get

ru1:/home/jqb/tmp$ uname -a
Linux ru1 2.4.18-27.7.xsmp #1 SMP Fri Mar 14 05:52:30 EST 2003 i686 unknown
ru1:/home/jqb/tmp$ /di/local/gcc-3.1.1/bin/jar --version
jar (fastjar) 0.92-gcc

Copyright 1999, 2000, 2001  Bryan Burns
Copyright 2002 Free Software Foundation
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
ru1:/home/jqb/tmp$ rm -f foo.jar; /di/local/gcc-3.1.1/bin/jar cf foo.jar -C foo bar -C foo bar
ru1:/home/jqb/tmp$ /di/local/gcc-3.1.1/bin/jar tf foo.jar
META-INF/
META-INF/MANIFEST.MF
bar
bar
ru1:/home/jqb/tmp$

Go figure.  (Note that the latter, though it doesn't exhibit the stated bug,
does put two copies of bar into the jar file, which the Sun version doesn't do.)

Ok, let's try it on another box, with x86 Solaris:

vk8:/home/jqb/tmp$ uname -a
SunOS vk8 5.7 Generic_106542-23 i86pc i386
vk8:/home/jqb/tmp$ /di/local/gcc-3.1.1/bin/jar --version
jar (fastjar) 0.92-gcc

Copyright 1999, 2000, 2001  Bryan Burns
Copyright 2002 Free Software Foundation
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*vk8:/home/jqb/tmp$ rm -f foo.jar; /di/local/gcc-3.1.1/bin/jar cf foo.jar -C foo bar -C foo bar
foo: No such file or directory
Error adding -C to jar archive!
vk8:/home/jqb/tmp$


So perhaps it's Solaris-specific.  I'm almost certain that /di/local/gcc-3.1.1
were installed from the identical virgin sources for all three machines.
And even if not, two jars are reporting the same version number but behaving
differently.

Ok, I'm looking at what I think is the source -- jartool.c, 48813 bytes,
dated Mar 18 2002,
  Revision 1.10  2002/01/03 04:57:56  rodrigc
  2001-01-02  Craig Rodrigues  <rodrigc@gcc.gnu.org>

Consider

       if(!strcmp(arg, "-C")){
	const char *dir_to_change = get_next_arg ();
	const char *file_to_add = get_next_arg ();
         if(!dir_to_change
	   || !file_to_add
	   || add_to_jar(jarfd, dir_to_change, file_to_add)){
           printf("Error adding %s to jar archive!\n", arg);
           exit(1);
         }
       }

That exhibits the second bug I noted,
     "Error adding -C to jar archive!"

Looking at add_to_jar,

   /* If new_dir isn't null, we need to change to that directory.  However,
      we also need to return to the old directory when we're done */
   if(new_dir != NULL){
     old_dir = getcwd(NULL, 0);

Well, it sounds good, but in fact there are 8 returns from that
file but only one restores the old directory; the other 7 not only
don't restore it, but leak the memory allocated by getcwd.
But those are error exits, and don't explain the observed bug.
What would explain it though, is if getcwd failed:

   if(old_dir != NULL){
     if(chdir(old_dir))
       perror(old_dir);

     free(old_dir);
   }

And in fact getcwd does return NULL on Solaris:

      EINVAL    The size argument is equal to 0.

getcwd(NULL, 0) is a Linux extension.  So there are
actually at least 4 bugs here (using -C as the
file name in an error message, not checking the
return value of getcwd for error, using a non-portable
feature, and not restoring the directory and freeing memory
when add_to_jar encounters an error), and I'm sure there
are a lot more, given the quality of the code.