Description of problem:
* "jar -x ...": extracted files are sometimes longer than archived files.
* '#define original_file file_put_into_the_archive'
* in Detail: for every byte 0x0a in the original_file, the extracted file
contains the bytes 0x0d, 0x0a . (1*)
Version-Release number of selected component (if applicable):
* gcc-3.2.2-5.src.rpm/fastJar/<files> compiled and linked with a Microsoft
Visual Studio C++ -compiler and -linker version 6.0 .
* depends on compiler and (1*) .
Steps to Reproduce:
1. you have a compiler / operating-system that makes a difference between text-
2. you have the byte 0x0a in the original file.
Actual results: see (1*)
* the extraced and the original_file should have the same length and the same
* see also line# 53 of gcc-3.2.2-5.src.rpm/.../fastJar/jartool.c,
Revision 1.6 2001/07/04 18:33:53 .
* at line# 264 of this file, the definition of "O_BINARY" is granted, even if
not used in posix(?).
* most (or all?) of the (file-)open(...) statements in the .../fastJar/<files>
are written with the O_BINARY-flag. so if compiler or operating system
distinguishes between binary and text-files, the files are opened in binary
* BUT: in function "extract_jar", line# 1458: create(...) is used for creating
the extraced file instead of open; with the above compiler this results in
open( ..., O_CREAT | O_TRUNC | O_RDWR | O_TEXT, ... ), the extacted file
is created in text-mode, and according to the microsoft-operating-system for
every LF=0x0a a CR=0x0d is prepended.
* suggestion: replace there create(...) with
open( ..., O_CREAT | O_TRUNC | O_RDWR | O_BINARY, ... ) ; exactly:
" f_fd = open( (const char *)filename, O_CREAT | O_TRUNC | O_RDWR | O_BINARY,
00644 ); "
* after applying this change to jartool.c, the compiled jar worked properly.
There is no O_BINARY nor O_TEXT on Linux, this report is misplaced.
Guess you want to 1) test whether contemporary GCC (4.0.x or HEAD) behaves the
same 2) if yes, report the bug to the correct place, i.e.