Menu

#339 1.30.1 fails to build on FreeBSD 13.1

1.30.x
closed-fixed
nobody
None
5
2022-08-01
2022-07-24
Daniel E
No

Fails to build on FreeBSD 13.1-RELEASE (amd64) with following error message:

src/compat/compat.c:456:16: error: use of undeclared identifier 'EWOULDBLOCK'
                        && errno != EWOULDBLOCK
                                    ^
src/compat/compat.c:480:16: error: use of undeclared identifier 'EWOULDBLOCK'
                        && errno != EWOULDBLOCK
                                    ^
2 errors generated.
*** [src/compat/compat.lo] Error code 1

Discussion

  • Thomas Orgis

    Thomas Orgis - 2022-07-24

    Well … that's what you get for trying to increase portability for platforms where EAGAIN != EWOULDBLOCK. Is this constant truly not defined on FreeBSD (doesn't POSIX suggest it should?) or do we need to make it appear somehow?

    Do we need a configure check that builds a program that compares EAGAIN to EWOULDBLOCK?

     
  • Daniel E

    Daniel E - 2022-07-24

    I guess this is what you're looking for?
    https://www.freebsd.org/cgi/man.cgi?write(2)

     
  • Thomas Orgis

    Thomas Orgis - 2022-07-24

    So did the FreeBSD project make a conscious decision to omit that name that doesn't seem to be too recently introduced (POSIX.1?)? https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html

    Well, regardless of addressing this lack of POSIX compliance in FreeBSD, this needs to be dealt with. I am wonderig if there is a system in the world that does indeed specify EWOULDBLOCK to a value different from EAGAIN. I could just drop it again, but the standard says I should check for this error, generally.

    So a silly configure test program it is? Just more preprocessor guards doesn't seem sensible.

     
  • Thomas Orgis

    Thomas Orgis - 2022-07-24

    OK, now I'm confused: https://www.freebsd.org/cgi/man.cgi?query=open(2) does mention EWOULDBLOCK. Now, does this value exist, or did it ever on FreeBSD?

     

    Last edit: Thomas Orgis 2022-07-24
  • Daniel E

    Daniel E - 2022-07-24

    I'm no expert on the subject but looking at man pages for write(2) (you can change releases) it looks like it got removed in FreeBSD 2.0

     
  • Thomas Orgis

    Thomas Orgis - 2022-07-24

    Interesting. Could you contact someone in the FreeBSD world about that being maybe just a mistake? It seems, though, that caring for EWOULDBLOCK is rather rare.

     
  • Warner Losh

    Warner Losh - 2022-07-25

    EWOULDBLOCK == EAGAIN in FreeBSD. Due to POSIX rules, though, if _POSIX_SOURCE is defined, we only define EAGAIN because _POSIX_SOURCE == POSIX_C_SOURCE=198808 which says 'don't define anything not in POSIX.1' and EWOULDBLOCK is not in POSIX.1. Otherwise is will be defines. is _POSIX_SOURCE being defined for some reason?
    [Edited to correct date of early posix]

     

    Last edit: Warner Losh 2022-07-25
  • Warner Losh

    Warner Losh - 2022-07-25

    Also, it's only newer versions of POSIX that define EWOULDBLOCK. I think 2008 issue 6 is where that's defined, but I've not done a full audit of the POSIX specs since it's the weekend...

     
  • Thomas Orgis

    Thomas Orgis - 2022-07-25

    Thanks for the detail! The reference I linked suggests it was there from the beginning and it would be odd if it weren't, but I am not able to find an earlier POSIX errno.h reference and don't have access to the full standard.

    Hm, but the standard does say that the errno values are supposed to be macros (not enum) … so I guess it's fine just to do an #ifdef here?

     
  • Thomas Orgis

    Thomas Orgis - 2022-07-25

    We just define _POSIX_SOURCE to get sigaction() (well, initially, at least).

     
  • Thomas Orgis

    Thomas Orgis - 2022-07-25

    I did that now … fine? Revision 5131:

    Index: NEWS
    ===================================================================
    --- NEWS    (revisión: 5127)
    +++ NEWS    (copia de trabajo)
    @@ -1,3 +1,8 @@
    +1.30.2
    +------
    +- Only use EWOULDBLOCK if the macro is defined (FreeBSD misses it for
    +   _POSIX_SOURCE).
    +
     1.30.1
     ------
     - mpg123:
    Index: src/compat/compat.c
    ===================================================================
    --- src/compat/compat.c (revisión: 5127)
    +++ src/compat/compat.c (copia de trabajo)
    @@ -451,8 +451,9 @@
                bytes   -= part;
                written += part;
            } else if(errno != EINTR && errno != EAGAIN
    -#ifndef __KLIBC__
    -           // OS/2 is funny with POSIX.
    +#ifdef EWOULDBLOCK
    +           // Not all platforms define it (or only in more modern POSIX modes).
    +           // Standard says it is supposed to be a macro, so simple check here.
                && errno != EWOULDBLOCK
     #endif
            )
    
     
  • Warner Losh

    Warner Losh - 2022-07-25

    We aren't supposed to define it if _POSIX_SOURCE is defined, since that's the language as it was in 1988, and EWOULDBLOCK isn't part of that. It wasn’t added until "Issue 4, Version 2" which was in 1995 around the time that the Open Group started minding the POSIX standard store...

    It might make sense to say #if defined(EWOULDBLOCK) && EWOULDBLOCK != EAGAIN since many implementations have them as the same value and some compilers like to warn about expressions that are apparently redundant like this. I have deep, mixed feelings about how helpful compilers have become. The #ifdef also works on systems that don't have EWOULDBLOCK at all (though they are somewhat rare these days: most are early System V or earlier based systems and OS/2 evidentally :).

    Now, having said this, almost nobody else is this pedantic when _POSIX_SOURCE is defined (or even when the more modern _POSIX_C_SOURCE define that came along in Issue 3 in 1993). Most available implementations that I've looked at either don't bother restricting the identifiers, or are spotty about restricting identifiers before Issue 6 (The 2001 version of POSIX) or Issue 7 (The 2008 version, still in force with technical corrections sometimes cited as 2017 or 2018 revision).

     
  • Warner Losh

    Warner Losh - 2022-07-25

    Oh, and yes, E* defines are guaranteed to be macros in POSIX compliant environments. It's explicitly spelled out in at least Unix95(Issue 4) and newer as well as SVID versions.

     

    Last edit: Warner Losh 2022-07-25
  • Daniel E

    Daniel E - 2022-07-26

    Still fails backporting rev 5131

     
  • Thomas Orgis

    Thomas Orgis - 2022-07-27

    Ah, sorry, I missed the second instance of EWOULDBLOCK. It's in the write and read functions. Care to check again with the changes of r5132?

     
  • Daniel E

    Daniel E - 2022-07-27

    Compile and runtime tested on 13.1-RELEASE (aarch64)
    Thanks!

     
  • Thomas Orgis

    Thomas Orgis - 2022-08-01
    • status: open --> closed-fixed
     

Log in to post a comment.