[Bug java/9532] jar -C flag is incompatible with Sun's (fastjar uses nonportable feature of getcwd)

[jim dot balter at cw dot com]

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 dot balter at cw dot com  2003-07-02 20:51 -------
Subject: Re:  jar -C flag is incompatible with Sun's (fastjar
 uses nonportable feature of getcwd)

On 7/2/03 10:23 AM, neroden at gcc dot gnu dot 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 at gcc dot gnu dot org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|ASSIGNED                    |RESOLVED
>          Resolution|                            |FIXED
> 
> 
> ------- Additional Comments From neroden at gcc dot gnu dot org  2003-07-02 17:23 -------
> Buffer won't be allocated recursively.

Is this supposed to be a response to my comment?  If so, it missed
the point, which wasn't about multiple allocation in space,
but rather multiple allocation, or rather multiple getcwd, in time.
jar cf x.jar -C foo a -C foo b -C foo c ..., as might be produced by
a script, would call getcwd each time, and getcwd, which must
track through the directory hierarchy, is an expensive operation
(more expensive on some systems than others, of course).

> I believe this bug is effectively fixed.

No disagreement, but I *still* think it would be better
(faster, more efficient) to allocate the buffer just once,
statically, and reuse the result:

     static char old_dir[MAXPATHLEN];
     ...
         /* getcwd if we didn't already */
         if(!*old_dir && !getcwd(old_dir, sizeof old_dir)){
         ...