From: Wietse Venema (no email)
Date: Mon Sep 01 2003 - 11:14:35 EDT
Carsten Hoeger:
> Hi,
>
> sorry, that I have to start that thread again, but I got a bugreport of a user
> insisting on sending attachments with a size > 2GB on his 64bit machine.
> So I just had a look at the code and found, that e.g. in master/master.c
> there's:
>
> if ((inherited_limit = get_file_limit()) < (off_t) INT_MAX)
> set_file_limit(INT_MAX);
>
> INT_MAX is always 4 bytes long, so it doesn't care on which platform I run
> postfix, I'll always get a max of 2147483648 bytes per file.
>
> So why not use the max size off off_t, e.g. using this code:
>
> #define FSIZE_MAX (off_t)1<<((sizeof(off_t)*8)-1)
>
> to determine the maximum size of a file?
How portable is this? The standard says nothing about the representation
of an off_t, and Postfix makes no assumptions about it. For all we
know it could be packed decimal (BCD) or roman numerals.
> If this would be okay, I would prepare and test a patch, but I want to discuss
> this before wasting my time.
>
> And btw.:
>
> in util/file_limit.c
>
> off_t get_file_limit(void)
> {
> off_t limit;
>
> [...] ifdef ULIMIT stuff removed
>
> struct rlimit rlim;
>
> if (getrlimit(RLIMIT_FSIZE, &rlim) < 0)
> msg_fatal("getrlimit: %m");
> limit = rlim.rlim_cur;
> return (limit < 0 ? INT_MAX : rlim.rlim_cur);
> }
>
> What is this test for?
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.
Wietse
|
|
|