[kaffe] concerns about large files and HP-UX in kaffe

[Riccardo]

Hello,

while analyzing warnings on HP-UX 10.20 I found troubles with symbols  
inside system headers (just warnings.. on stuff like __xxxx64()).
Further analysis shows that this happens when _FILE_OFFSET_BITS is set  
to 64 (without ay further options flags or system includes).

now together with _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE they are  
posix flags to regulate the usage of the functions, either by defining  
that the old function name xx() works as 64bit or by defining a xx64()  
version.

read here:

http://www.pimpworks.org/hp/relnotes/lg_files.txt

now I don't understand why on my hp-ux 10.20 box I get these warnings.  
(it might be interesting to check other hp-ux 10.20 boxes...).

interesting is that my os should support large files (read  
http://hpwww.epfl.ch/HPUX/10.20RelNotes for further notes, esp. the  
section
Large Files
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 
@@@@@
For 10.20, HP-UX now supports files up to 128GB in size.  The prior  
limit was
2GB.)

but the first document says

6.1.4 Determining if large-files are supported

For developers that want to write code that is portable between
systems that support large files and sys- tems that do not support
large files, two announcement macros are available. These announcement
mac- ros are _LFS_LARGEFILE and _LFS64_LARGEFILE.


apparently on my computer, when using a test file and gcc 2.95,  
_LFS_LARGEFILE is not 1. SO I am confused. Maybe this causes the many  
warnings. Also these warnings could cause malfunction...

Maybe it is that 10.20 headers have torubles, but I doubt this, it is  
something too evident... Even hello world causes warnings if 64bit is  
on and a system header file is included.

any help welcome, especially by people with access to 10.20 systems  
(and possibly verifying 11.x systems...)

in any case, I don't know what we are doing, but posix says

   1. Make the program aware of large files without actually supporting
      them.  Look for the new open() and stat() errors and, if  
encountered,
      take appropriate actions.  For example, if your application is a
      browser that currently exits when stat fails, it can instead be
      changed to display an appropriate message and then continue.

   2. Use standard types and calls, but compile the program in the
      environment that uses 64 bits for the relevant types.  Note that
      other source changes will most likely be necessary to correctly
      support the larger data types.

   3. Use the new *64() calls in the 32-bit compile environment.  This
      involves explicitly coding the *64() names into the source code.
      This should only be done when a specific portion of the application
      needs to be large file aware, while other parts do not.  This  
approach
      is not recommended if the alternative described above can be used.

the current behavior is that the following kind of definition is  
activated in the system headers

static xxx() { return __xxx64() }

which would mean that we use standard names and want then to be 64bit.

all __xxx64() definition in these files result undefined (interestingly  
this is for C.. if it was c++ the symbols would have been defined as  
"extern")

so maybe it is really some header imprecision ? or did we find some  
corner case ? I wonder... also the fact that the 64bit macro that  
should return 1 returns 0 here...

Cheers,
    Riccardo