Bug #965
closed
'FILE' undefined on -DEVEL?
Added by wa1ter over 16 years ago.
Updated almost 16 years ago.
Description
While trying to build a pkgsrc package, the configure step failed because this
code won't compile on DFly:
#include <sys/types.h>
#include <inttypes.h>
#include <stdint.h>
#include <stddef.h>
#include <unistd.h>
#include <stdio.h>
typedef FILE ac__type_new_;
int
main ()
{
if ((ac__type_new_ *) 0)
return 0;
if (sizeof (ac__type_new_))
return 0;
;
return 0;
}
AFAICT, the reason is that FILE is undefined, or wrongly defined. The same
code compiles on the other BSDs and linux, so we are different somehow.
Is this by intention, and why?
Thanks.
FILE is an incomplete type. That is intentional. The only operation
ISO C90 and C99 allow on FILE are pointer ops. Copying is explicitly
prohibited. The most sane way to enforce that is to make it an
incomplete type. Checking the existance of FILE is just bogus.
Joerg
I think sizeof(FILE) is disabled intentionally. No program should depend on that
Regards
Jonas
On 3/9/08, walt <wa1ter@myrealbox.com> wrote:
While trying to build a pkgsrc package, the configure step failed because this
code won't compile on DFly:
#include <sys/types.h>
#include <inttypes.h>
#include <stdint.h>
#include <stddef.h>
#include <unistd.h>
#include <stdio.h>
typedef FILE ac__type_new_;
int
main ()
{
if ((ac__type_new_ *) 0)
return 0;
if (sizeof (ac__type_new_))
return 0;
;
return 0;
}
AFAICT, the reason is that FILE is undefined, or wrongly defined. The same
code compiles on the other BSDs and linux, so we are different somehow.
Is this by intention, and why?
Thanks.
type, search on pkgsrc-users for "[PATCH] databases/db4" for the patch to fix
this ;)
The POSIX/SUSv3 standards don't say anything about what FILE should be (other
than that it should be defined with typedef) ... so whatever it is, as long as
it's defined, it's standard compliant :P
Also available in: Atom
PDF