Re: Fwd: -D_FILE_OFFSET_BITS

2002-12-09 Thread Gerhard Tonn
On Sunday 08 December 2002 21:30, Russell Coker wrote:

  OK, I'm getting exactly the same issues on S/390 (raptor) as I do on the
 ARM machines.


The test program works fine for me. I have compiled it with gcc-2.95 on 
raptor. 

[EMAIL PROTECTED]:~$ gcc -D_FILE_OFFSET_BITS=64 hole.cpp
[EMAIL PROTECTED]:~$ ./a.out d 1000
Seeking to 1000 

 Obviously I am doing something very wrong, could someone please tell me
 what it is?

 This list seems to get a faster response than debian-arm...

 Once I get this issue solved I'll have the entire user-space code for SE
 Linux running on S/390.  ;)


Great.

Gerhard



Re: Fwd: -D_FILE_OFFSET_BITS

2002-12-09 Thread Gerhard Tonn
On Sunday 08 December 2002 21:30, Russell Coker wrote:

  OK, I'm getting exactly the same issues on S/390 (raptor) as I do on the
 ARM machines.

 Obviously I am doing something very wrong, could someone please tell me
 what it is?


Maybe the problem is caused by some of the warnings like

msgget_s.c:37: warning: comparison is always true due to limited range of 
data type

This is due to the fact that char is per default unsigned on powerpc, arm and 
s390. Using a char to compare against EOF is also broken on the other 
platforms. You should use int instead of char, since EOF should be handled 
differently than the char 0xff.

Gerhard



Fwd: -D_FILE_OFFSET_BITS

2002-12-08 Thread Russell Coker
OK, I'm getting exactly the same issues on S/390 (raptor) as I do on the ARM 
machines.

Obviously I am doing something very wrong, could someone please tell me what 
it is?

This list seems to get a faster response than debian-arm...

Once I get this issue solved I'll have the entire user-space code for SE Linux 
running on S/390.  ;)

--  Forwarded Message  --

Subject: -D_FILE_OFFSET_BITS
Date: Sat, 7 Dec 2002 13:34:27 +0100
From: Russell Coker [EMAIL PROTECTED]
To: Debian Arm debian-arm@lists.debian.org

I've just started trying to get SE Linux going on ARM.  The Makefile for one
of the important utility programs (the program to find all the files on the
file system and relabel them to the correct security context) uses
-D_FILE_OFFSET_BITS=64 (it needs to stat() every file on the file system
including those over 2G in size).

When I compile this on debussy it fails, among other problems the code wants
to use  operations for hashing an ino_t.

I've attached a little test program I use for creating large files with
 holes. On my x86 systems I used to be able to create large files with the
 attached program (although recently it has started giving signal 25 when I
 try).

On debussy my hole program refuses to create large files, but cat /dev/zero

 file will bring a file over the 2G limit without any problems.

Any tips on getting large file support portable (or on ./configure tests to
 do it right)?

Currently I'm just using -D_FILE_OFFSET_BITS=32 and it seems to work OK.

--
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

---


-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page
#include stdio.h
#include stdlib.h
#include unistd.h
#include linux/unistd.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h

#if ! ( defined __USE_LARGEFILE64 || defined __USE_FILE_OFFSET64 )
_syscall5 (int,  _llseek,  uint,  fd, ulong, hi, ulong, lo,
   loff_t *, res, uint, wh);
#endif

int main(int argc, char *argv[])
{
  if(!argv[1] || !argv[2])
  {
printf(usage: hole filename size\n);
return 1;
  }
  int fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
  if(fd == -1)
  {
printf(Can't open %s\n, argv[2]);
return 1;
  }
  long long size = atoll(argv[2]);
  printf(Seeking to %lld\n, size);
  loff_t retval;
#if defined __USE_FILE_OFFSET64
retval = lseek(fd, size, SEEK_SET);
#elif defined __USE_LARGEFILE64
retval = lseek64(fd, size, SEEK_SET);
#else
loff_t result;
unsigned long high = int(size  32);
printf(high:%d\n, high);
retval = _llseek (fd, high,
  ((unsigned long long) size)  0x,
  result, SEEK_SET);
if(retval == 0)
  retval = result;
#endif
  if(retval != size)
  {
printf(Can't seek to %lld\n, size);
return 1;
  }
  char c = 'A';
  if(write(fd, (void *)c, 1) != 1)
  {
printf(Can't write to file.\n);
return 1;
  }
  close(fd);
  return 0;
}


Re: Fwd: -D_FILE_OFFSET_BITS

2002-12-08 Thread Bastian Blank
On Sun, Dec 08, 2002 at 09:30:58PM +0100, Russell Coker wrote:
[...]

i try to compile the test program. first it isn't c, so i need to fix
it. i compile it with gcc 3.2 and -D_FILE_OFFSET_BITS=64.
it seems to work fine.

| $ ./test ./test1 1000
| Seeking to 1000
| $ ls -al test1
| -rw---1 waldiDebian   1001 Dec  8 22:41 test1

bastian

-- 
The face of war has never changed.  Surely it is more logical to heal
than to kill.
-- Surak of Vulcan, The Savage Curtain, stardate 5906.5


pgpxBZ476bZTm.pgp
Description: PGP signature