Regarding EFBIG error while opening a file using catopen() function

Mon Dec 12 10:25:19 GMT 2022

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