#2024 'off64_t' does not name a type

[Nicholas]

With the latest GCC package, including io.h either directly or indirectly (for example, via unistd.h), causes the following errors:

c:\mingw\include\io.h:301:14: error: 'off64_t' does not name a type
 __CRT_INLINE off64_t lseek64 (int, off64_t, int);
              ^
c:\mingw\include\io.h:302:14: error: 'off64_t' does not name a type
 __CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
              ^

Information requested:

$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable
-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --dis
able-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs -
-with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-sy
stem-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-l
ibintl-prefix=/mingw
Thread model: win32
gcc version 4.8.1 (GCC)

Minimal test case:
#include <unistd.h> int main() {}

It worked fine with a previous GCC version (was it 4.7.2?).

[Trent Gamblin]

Came to report this. Freetype uses the -ansi switch when compiling which causes off64_t not to be defined.

[Nicholas]

I forgot to mention the command and this issue tracker doesn't seem to have an "Edit" feature.

Anyway, this works fine when compiled without any switches. The problem described occurs when one of -ansi, -std=c++11, -std=c++03 and -std=c++98 is used.

[Earnie Boyd]

It wasn't the GCC version update that resulted in this issue.

I think the fix is to change the io.h lseek64 to use _off64_t instead of off64_t.

The task for me is to review the off64_t definitions in sys/types.h.

[jdre de vogel]

Thx this helped. Did change all 4 off64_t to _off64_t and got past it. Up to the next error!

[HighCommander4]

I had the same problem upon updating to 4.8.1. I can confirm that using _off64_t instead of off64_t in io.h resolves the problem.

[Earnie Boyd]

Resolved in 4.1-dev branch pending release.

[Keith Marshall]

Except that there's an underlying bug, for which a correction should be applied in every active development/release branch. This should not have to wait for 4.1

[Brandon White]

A similar issue exists in unistd.h for int ftruncate(int, off_t);
I believe it needs a leading underscore as well, such as int ftruncate(int, _off_t);

[Thorsten Otto]

Using _off_t/_off64_t instead of off_t/off64_t in the headers is one thing, but what is the reason for not declaring off_t? Lots of libraries/applications are using that type (e.g. in zlib.h both types are used). Can someone explain what those types have to do with __STRICT_ANSI__ being defined?

[Keith Marshall]

off_t is a POSIX type, but not an ISO-C (ANSI) type. If you compile with -ansi, (or any of the other standards selection options which asserts __STRICT_ANSI__ checking), you cannot expect it to be defined by the compiler implementation; it is a non-standard option with user-namespace semantics, so you need to define it.

off64_t is similar, but currently not even a POSIX standard type, AFAIK; it's a GNU extension type.

If you compile with any of the standards selection options, the compiler should check for strictly standards conforming usage; it is correct that it requires you to define such non-conforming types yourself.

[HighCommander4]

I have upgraded to the latest mingw32-w32api package (4.0.3-1), but am still encountering this error. Was this not fixed?

[Kelly Sommers]

I also hit this problem in io.h trying to compile this code https://github.com/wg/wrk

I set -I/include in the Makefile so that the headers would be picked up (this is not very intuitive to people installing the -dev packages and still compiles fail).

The result is the following compile error:

c:\mingw\include\io.h:301:1: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int, off64_t, int);

The Makefile compiles with --std=c99

[Michael Heilmann]

Is there still no solution/update via mingw-get? The language revision/standard/extension being used (---std=c99,--std=gnuc99,...) should not break (the substitutes of) operating system header files. In fact, both are almost unrelated (except of that a system header might require a particular revision/standard/extension) which is - usually - not the case.

[Keith Marshall]

I don't see the problem, using mingwrt-3.20, and I rolled mingw-get back to deliver that, several weeks ago. (Do be sure to uninstall all wsl-4.x -- a.k.a. mingwrt-4.x and w32api-4.x -- components, before you update mingw-get's catalogue, and then install the 3.20 versions ... 4.x also introduced an incompatible package structure, which will confuse mingw-get if it loses the catalogue references while the broken packages are still installed).

Are you still persisting with the TARFUBAR wsl-4.x crap? If so, get rid of it -- there is no one actively maintaining it.

[Earnie Boyd]

The mear use of --std=c99 mandates -ansi as well per GCC rules. It is the -ansi that is defineing the __STRICT_ANSI__ macro. If you want it to change you need to take it up with GCC.

[Michael Heilmann]

Indeed it works. Sadly the installer does not show such downgrades :)

Back to the topic: I am a bit worried about the ideas that seem to be adopted about __STRICT_ANSI__, --std=...,--ansi and other options. For instance in https://sourceforge.net/p/mingw/bugs/2104/#1fea/1540 it is said that enabling ANSI-compliance would exclude Posix/Linux system headers/definitions like off_t? The non-availability of Posix/Linux operating system headers is never enforced (nor their availability implied, for that matter) by any language standard from ANSI/ISO may it be C89,C90,C99,...? If headers are modified based on such assumptions, a lot of problems will follow for absolutely no reason. See also https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html or simply the ANSI standard if there are doubts. If those headers COMPILE under a given language applied is of course a different question.

[Keith Marshall]

Back to the topic: I am a bit worried about the ideas that seem to be adopted about __STRICT_ANSI__, --std=...,--ansi and other options. For instance in https://sourceforge.net/p/mingw/bugs/2104/#1fea/1540 it is said that enabling ANSI-compliance would exclude Posix/Linux system headers/definitions like off_t?

POSIX.1 is actually quite explicit on this:
http://pubs.opengroup.org/onlinepubs/9699919799/nframe.html

Note that, while you may expect that a strictly POSIX.1 conforming system would provide all POSIX.1 standard features, it is incumbent on the user of a non-conforming system -- such as MinGW.org provides on MS-Windows -- to ensure that appropriate feature test macros are defined, to achieve whatever level of conformance is required; (simply including a POSIX.1 header is not necessarily sufficient). Now, MinGW.org does, in general offer some degree of POSIX.1 conformance, by defining _POSIX_C_SOURCE = 200809L by default, (although this does not guarantee full POSIX.1-2008 conformance, because significant parts of the necessary implementation are not readily supportable); however, when a user compiles with -ansi, or any of the other options which imply __STRICT_ANSI__, the default assignment of _POSIX_C_SOURCE is not performed -- if you want it, then you must assign it, to re-enable those associated features which may be supported in consequence.

Having said this, I will acknowledge that past MinGW.org maintainers have exhibited a rather haphazard attitude to the use of feature test macros, (to the extent of inventing an insane proliferation of entirely arbitrary non-standard names, and eschewing standards such as _POSIX_C_SOURCE). I'd like to see a rationalization of this situation, so if you identify a combination of feature test macros which doesn't behave as any applicable standard would suggest, then please raise a new ticket, to let us know.

[Earnie Boyd]

I agree that the __STRICT_ANSI__ and other macro controllers have been a bit too lax. This has caused ANSI incompliant code throughout the industry. That doesn't mean it should continue. The use of -Wall and -pendantic should always occur when using GCC and -ansi should be applied when needing to be any compiler conforming. The only reans to use -std=c99 is for wanting to ensure that yuor code meets with ANSI 1999 standards so that other ANSI 1999 standards compliant compilers might have a chance to compile the code.

Now if the library compiler headers do not conform that is a bug for MinGW and we need to resolve that issue. We should not conform toward noncompliant use.

[Keith Marshall]

The only [reason] to use -std=c99 is for wanting to ensure that [your] code meets with ANSI 1999 standards so that other ANSI 1999 standards compliant compilers might have a chance to compile the code.

No, that isn't strictly true. The more important reason is actually to ensure that, where subtle semantic changes may occur in progressing from one version of the standard to the next, the appropriate semantics are understood at compile time, and that new features are appropriately interpreted, with applicable semantics. Without this additional reason, there would be no justification for ever specifying -ansi, nor any of its -std=... derivatives, as anything other than a pre-release maintainer check for strict ISO-C conformance; (I do agree, however, that these options are all too often over used, unnecessarily, in production builds).

BTW, specifying -pedantic falls in the same category -- may be useful as a pre-release check, but undesireable in final production builds. It will often make the compiler unexpectedly verbose, if used with less than -std=c99.

[Vasili Gavrilov]

Just installed fresh cygwin with mingw32 4.7.3, and having the same issue (including <unistd.h> causes unknown type names error when used with -ansi or -std=c99 switches).

Compiling legacy code (which was working with older versions of mingw) fails due to the presence of -ansi switch and <unistd.h> included in the code. To be able to compile, I had to remove the switches manually, which seems to be wrong.

If there is a fix, will it go soon to the cygwin mingw distribution? Lack of backward compatibility may hurt the legacy applications. BTW I also tried under 64bit cygwin version with the same results.

$ i686-pc-mingw32-gcc --version
i686-pc-mingw32-gcc (GCC) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
CYGWIN_NT-6.1-WOW OND2C01210980 2.4.1(0.293/5/3) 2016-01-24 11:24 i686 Cygwin

$ cat test.c

#include <unistd.h>
int main(void){}

$ i686-pc-mingw32-gcc -c test.c

$ i686-pc-mingw32-gcc -c -ansi test.c
In file included from /usr/i686-pc-mingw32/sys-root/mingw/include/unistd.h:36:0,
from test.c:1:
/usr/i686-pc-mingw32/sys-root/mingw/include/io.h:301:1: error: unknown type name ‘off64_t’
/usr/i686-pc-mingw32/sys-root/mingw/include/io.h:301:36: error: unknown type name ‘off64_t’
/usr/i686-pc-mingw32/sys-root/mingw/include/io.h:302:1: error: unknown type name ‘off64_t’
/usr/i686-pc-mingw32/sys-root/mingw/include/io.h:302:39: error: unknown type name ‘off64_t’
In file included from test.c:1:0:
/usr/i686-pc-mingw32/sys-root/mingw/include/unistd.h:65:20: error: unknown type name ‘off_t’

$ cat test.c | sed /unistd/d > test2.c

$ i686-pc-mingw32-gcc -c -std=c99 test2.c

$ i686-pc-mingw32-gcc -c -ansi test2.c

Thanks and Regards

[Keith Marshall]

Just a few comments:
1. First and foremost, this is already fixed, in our source repository; see [43446e].
2. GCC-4.7.3 is ancient history; our current release is GCC-4.9.3
3. In any case, this is not a compiler version issue; it was a bug, now fixed, in mingwrt headers.
4. This is the bug tracker for MinGW.org; we do not support cygwin, and we no longer share a repository with them.

[Vasili Gavrilov]

Thanks for the details/clarifications!
I thought, you are collaborating with cygwin and interested in more robust version under any environment were people may use the library, while cygwin one of the most popular.
Anyway, thanks so much