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

[Corinna Vinschen]

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