[Bug c/29764] New: casting as off64_t gives wrong address for mmaped file using sendfilev64 on solaris

["dbb at st-andrews dot ac dot uk" <gcc-bugzilla at gcc dot gnu dot org>]

phantom# /usr/sfw/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
/gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

This is a follow up to apache bug 34963
http://issues.apache.org/bugzilla/show_bug.cgi?id=39463

It seems to be present on at least Solaris 9 and 10.

I'm not really sure how to describe this but the below text from a Sun Engineer
with sample code explains / demonstrates the problem.

Source code from Sun engineer to demonstrate problem.

-------- Cut here --------
#include <stdio.h>
#include <sys/sendfile.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <unistd.h>

int main (void)
{
  sendfilevec64_t sfv[3];
  int mmapfd;
  void *addr;

  /* Open a file to mmap */
  if ((mmapfd = open ("/lib/libc.so", O_RDONLY)) == -1)
  {
    perror ("open of /lib/libc.so failed");
    exit (1);
  }

  /* mmap file */
  if ((addr = mmap (NULL, 8192, PROT_READ, MAP_SHARED, mmapfd, 0)) ==
MAP_FAILED)
  {
    perror ("mmap failed");
    exit (1);
  }
  close (mmapfd);
  fprintf (stdout, "mmap() done. addr = %p\n", addr);

  sfv[0].sfv_off = (off64_t)addr;
  sfv[1].sfv_off = (long)addr;
  sfv[2].sfv_off = (unsigned long)addr;

  fprintf (stdout, "Value of sfv_off[0] = %llu\n", sfv[0].sfv_off);
  fprintf (stdout, "Value of sfv_off[1] = %llu\n", sfv[1].sfv_off);
  fprintf (stdout, "Value of sfv_off[2] = %llu\n", sfv[2].sfv_off);

  exit (0);
}

-------- Cut here --------

As you can see, it mmap's a file, then takes the same value and casts it as an
off64_t (which it should be according to the definition of the struct
sendfilevec64_t), and also as a "long" (which I believe the Apache apr_off_t
type reduces to), then finally as an unsigned long.

This was compiled with Sun's cc compiler (from Studio 10 or 11 I think). The
output was this:

$ cc -D_LARGEFILE64_SOURCE -o test test.c
$ ./test
mmap() done. addr = ff390000
Value of sfv_off[0] = 4281925632
Value of sfv_off[1] = 18446744073696509952
Value of sfv_off[2] = 4281925632

The correct value is given when cast either as the off64_t or as an unsigned
value. When compiled and run using gcc (I happen to have version 3.4.3), the
results are:

$ gcc -Wall -D_LARGEFILE64_SOURCE -o test test.c
test.c: In function `main':
test.c:32: warning: cast from pointer to integer of different size
$ ./test 
mmap() done. addr = ff390000
Value of sfv_off[0] = 18446744073696509952
Value of sfv_off[1] = 18446744073696509952
Value of sfv_off[2] = 4281925632


Here, the correct value is returned if an unsigned long is specified. I think
there are two issues here:

        1) If the correct type "off64_t" is used, gcc produces incorrect
results. This would have to be investigated and taken up with the GCC team.
        2) The data type "apr_off_t" is defined as a long, where it could (or
should?) be defined as unsigned long.

The obvious way forward to prevent any compiler dependencies would be to change
the apr_off_t data type, but this is Apache's call.


Please note that the above program is provided as is, and is only designed to
demonstrate a particular point. It is a bit crude really, but I hope it serves
its purpose!


-- 
           Summary: casting as off64_t gives wrong address for mmaped file
                    using sendfilev64 on solaris
           Product: gcc
           Version: 3.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dbb at st-andrews dot ac dot uk


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