It's somewhat rude to send such a request to everybody and the kitchen
sink.
This belong on the cygwin ML, so please keep it here.
On Dec 12 10:40, Kavita Gore via Cygwin wrote:
> Hi all,
>
> I'm getting errno 27[EFBIG] file too large while opening catalogue with
> catopen() function in the cygwin-32bit version.
>
> [...]
> #define FILENAME TEMP.CAT
>
> buffer = catopen(FILENAME, 0);
> if (buffer != (nl_catd) - 1)
> {
> printf("File open successfully");
> }
> else
> {
> printf("errno: %d\n", errno);
> }
>
> While debugging using gdb.I've found that st.st_size is 0 and As per my
> understanding struct stat.st_size is declared as off_t, which is most
> probably signed, and resolves to long (signed by default).
Since you're running gdb anyway, why don't you *ask* gdb what type
off_t is?
(gdb) ptype off_t
type = long long
> So if SIZE_T_MAX does not fit into 2^31-1 (it most probably does not) it
> will appear as negative in the comparison.
No, under implicit type conversion rules, the comparison is well
defined. size_t is 32 bit on 32 bit systems, off_t is 64 bit. So the
comparison will convert __SIZE_MAX__ losslessly to long long. On 64 bit
systems, size_t is 64 bit, off_t is 64 bit. The comparison will be
performed unsigned, thus it will never be true.
$ cat > x.c <<EOF
#define _GNU_SOURCE 1
#include <stdio.h>
#include <stdlib.h>
int
main (int argc, char **argv)
{
off_t o = strtoll (argv[1], NULL, 0);
if (o > __SIZE_MAX__)
puts ("too big");
}
EOF
$ gcc -g -o x x.c
On 32 bit:
$ ./x 0
$ ./x 1
$ ./x 0xffffffff
$ ./x 0x100000000
too big
On 64 bit:
$ ./x 0
$ ./x 1
$ ./x 0xffffffff
$ ./x 0x100000000
$ ./x 0xffffffffffffffff
$ ./x 0x7fffffffffffffff
$
> I'd like to know the reason why I'm getting this error and How it can be
> resolved as it is a blocker in my task.
You may have to debug this a bit further.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
