From: Matthias Andree (no email)
Date: Mon Sep 01 2003 - 15:53:54 EDT
Carsten Hoeger <> writes:
> I might not have your programming experience, but all platforms I know (pc and
> not pc) off_t is either a long or a int type. I am a down-to-earth person, so
> I don't care too much for hypothetical discussions, so I'll give up
> here.
off_t is a signed integer type to hold a file size.
Does the situation improve through this procedure?
1. make tidy
2. make makefiles CCARGS='-D_FILE_OFFSET_BITS=64'
3. make
I haven't researched whether this helps rlim* stuff.
According to glibc which you're likely to use:
"- Macro: _FILE_OFFSET_BITS
This macro determines which file system interface shall be used,
one replacing the other. Whereas `_LARGEFILE64_SOURCE' makes the
64 bit interface available as an additional interface,
`_FILE_OFFSET_BITS' allows the 64 bit interface to replace the old
interface.
If `_FILE_OFFSET_BITS' is undefined, or if it is defined to the
value `32', nothing changes. The 32 bit interface is used and
types like `off_t' have a size of 32 bits on 32 bit systems.
If the macro is defined to the value `64', the large file interface
replaces the old interface. I.e., the functions are not made
available under different names (as they are with
`_LARGEFILE64_SOURCE'). Instead the old function names now
reference the new functions, e.g., a call to `fseeko' now indeed
calls `fseeko64'.
This macro should only be selected if the system provides
mechanisms for handling large files. On 64 bit systems this macro
has no effect since the `*64' functions are identical to the
normal functions.
This macro was introduced as part of the Large File Support
extension (LFS)."
>> Postfix falls UPWARDS to INT_MAX. Look at the code.
>
> Anyway, you are using INT and not LONG for whatever reason.
> If you don't want to tell me why, well, I also don't care.
With proper includes, the code in question, "limit < 0 ? INT_MAX :
blah", will never be executed because rlim_t, thus limit, is an unsigned
type, so (limit < 0) is always a boolean "false" and the original value
is returned. If you think _THIS_ is the place where it breaks, dig up
the actual "rlim_t" definition (unsigned long long on SL8.1).
IOW: if this INT_MAX "limitation" kicks in, your include files are
broken.
>> > > This is pampering for brain-dead Linux boxes that returned an
>> > > unsigned 4GB value into a signed integer, resulting in a negative
>> > > file size result.
(which was a standard violation BTW)
> Do you know a standard, that requires getrlimit() to return something which
> can be assigned to a off_t type value without changing the algebraic
> sign?
There is none. off_t is a signed type, rlim_t is an unsigned
type. RLIM_INFINITY is 2^64-1 on Linux (18.447*10^18), no matter which
$ARCH.
You'll always have to clamp to the maximum off_t (9.223*10^18 on 64-bit
off_t and 2.147*10^9 on 32bit).
Cast the rlim_t-typed result to off_t, if it's negative, the register
has overflown and you need a sane fallback.
-- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95
|
|
|