#2104 lseek64() in io.h needs protected by __STRICT_ANSI__ filter.

WSL
assigned
None
Bug
none
Feature_in_WSL_4.1
False
2015-02-24
2013-10-13
No

I tried to compile Freetype with mingw but I'm getting errors at a certain point.
This is a small extract as example:

In file included from c:\mingw\include\unistd.h:36:0,
                 from c:\mingw\include\zconf.h:452,
                 from c:\mingw\include\zlib.h:34,
                 from C:/MinGW/msys/1.0/home/Claudio/freetype-2.5.0/src/gzip/ftg
zip.c:50:
c:\mingw\include\io.h:301:1: error: unknown type name 'off64_t'
 __CRT_INLINE off64_t lseek64 (int, off64_t, int);
 ^
c:\mingw\include\io.h:301:36: error: unknown type name 'off64_t'
 __CRT_INLINE off64_t lseek64 (int, off64_t, int);
                                    ^
c:\mingw\include\io.h:302:1: error: unknown type name 'off64_t'
 __CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
 ^
c:\mingw\include\io.h:302:39: error: unknown type name 'off64_t'
 __CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
                                       ^

This happens because if __STRICT_ANSI__ is defined, then _off64_t and _off_t continue to be defined by sys/types.h, but off64_t and off_t do not.
For this reason, some functions, including the lseek64 showed in the above example, will crash the compilation process.
The first thing that I though was to fix these declarations in a manner like this:

#ifndef __STRICT_ANSI__
__CRT_INLINE off64_t lseek64 (int, off64_t, int);
__CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
#else
__CRT_INLINE off64_t lseek64 (int, __int64, int);
__CRT_INLINE off64_t lseek64 (int fd, __int64 offset, int whence) {
#endif

I'm going to attach a patch with the fix described above; however, if you are thinking on a different solution, I can try to provide a different patch with the fix you prefer.

Sincerely,

Carlo Bramini

Discussion

  • Carlo Bramini

    Carlo Bramini - 2013-10-13

    I must also write that the presence of __STRICT_ANSI__ makes also other libraries to crash, for example the absence of off_t makes to crash ZLIB.H

    Sincerely,

    Carlo Bramini

    PS: sorry for the disaster in previous message, I did not know that some characters could be interpreted as special format identifiers...

     
    Last edit: Carlo Bramini 2013-10-13
    Attachments
  • Earnie Boyd

    Earnie Boyd - 2013-10-13
    • status: unread --> closed
    • Resolution: none --> duplicate
     
  • Earnie Boyd

    Earnie Boyd - 2013-10-13

    This is a duplicate of [#2046].

    Maybe use the search feature of the ticketing system would prevent duplicate tickets?

     

    Related

    Issues: #2046

  • Carlo Bramini

    Carlo Bramini - 2013-10-14

    Excuse me... initially I was checking IO.H and not also UNISTD.H, so that's why that bug escaped to my attention when I was looking in the list. Anyways, as I wrote in the previous message, I also would like to signal that the absence of off_t breaks the usage of ZLIB 1.2.8.
    This simple test program:

    #define HAVE_UNISTD_H
    #define __STRICT_ANSI__
    #include <zlib.h>
    

    won't compile in my MINGW environment, while it worked fine in CYGWIN and UBUNTU.
    Sorry for the trouble.
    Sincerely,
    Carlo Bramini.

     
    • Earnie Boyd

      Earnie Boyd - 2013-10-14

      off_t isn't ANSI compliant so it will not be available when __STRICT_ANSI__ is defined; however _off_t will be. I'm thinking lseek64 should not be available for __STRICT_ANSI__ either which makes your patch not workable. MSDN doesn't have any version of lseek64 but does have _lseeki64. I'll modify the ticket subject to target lseek64 only.

       
  • Keith Marshall

    Keith Marshall - 2013-10-14

    Sigh. I do wish folks would use the "preview" feature, so they could see -- and fix -- their borked markup, and I wouldn't have to keep doing so.

     
  • Keith Marshall

    Keith Marshall - 2013-10-14
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,8 +1,7 @@
     I tried to compile Freetype with mingw but I'm getting errors at a certain point.
     This is a small extract as example:
    
    -
    -
    +~~~~
     In file included from c:\mingw\include\unistd.h:36:0,
                      from c:\mingw\include\zconf.h:452,
                      from c:\mingw\include\zlib.h:34,
    @@ -20,13 +19,14 @@
     c:\mingw\include\io.h:302:39: error: unknown type name 'off64_t'
      __CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
                                            ^
    +~~~~
    
    -
    -This happens because if __STRICT_ANSI__ is defined, then _off64_t and _off_t continue to be defined by sys/types.h, but off64_t and off_t do not.
    -For this reason, some functions, including the lseek64 showed in the above example, will crash the compilation process.
    +This happens because if `__STRICT_ANSI__` is defined, then `_off64_t` and `_off_t` continue to be defined by sys/types.h, but `off64_t` and `off_t` do not.
    +For this reason, some functions, including the `lseek64` showed in the above example, will crash the compilation process.
     The first thing that I though was to fix these declarations in a manner like this:
    
    +~~~~
     #ifndef __STRICT_ANSI__
     __CRT_INLINE off64_t lseek64 (int, off64_t, int);
     __CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
    @@ -34,6 +34,7 @@
     __CRT_INLINE off64_t lseek64 (int, __int64, int);
     __CRT_INLINE off64_t lseek64 (int fd, __int64 offset, int whence) {
     #endif
    +~~~~
    
     I'm going to attach a patch with the fix described above; however, if you are thinking on a different solution, I can try to provide a different patch with the fix you prefer.
    
     
  • Earnie Boyd

    Earnie Boyd - 2013-10-14
    • summary: IO.H and UNISTD.H crash if __STRICT_ANSI__ is defined --> lseek64() in io.h needs protected by __STRICT_ANSI__ filter.
    • status: closed --> assigned
    • assigned_to: Earnie Boyd
    • Resolution: duplicate --> none
     
    Last edit: Earnie Boyd 2013-10-14
  • Carlo Bramini

    Carlo Bramini - 2013-10-19

    I attached a new patch that it should fit for your request.
    Thank you very much.
    Sincerely,
    Carlo Bramini.

     
    Attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks