[9fans] ape/errno.h

[Jeff Sickel]

I'm not familiar with the full history of /sys/include/ape/errno.h, but it looks like EISCON should be EISCONN to fit with other systems that at least pretend to be POSIX compliant. SunOS 5.11 did have EISCON, but...


e.g.:

FreeBSD 9.0 /usr/include/errno.h && Mac OS X 10.8 (POSIX-compliant now) /usr/include/sys/errno.h both have:

#define EISCONN 56 /* Socket is already connected */



/sys/include/ape/errno.h:

#define EISCON 53

[erik quanstrom]

Post by Jeff Sickel
I'm not familiar with the full history of /sys/include/ape/errno.h, but it looks like EISCON should be EISCONN to fit with other systems that at least pretend to be POSIX compliant. SunOS 5.11 did have EISCON, but...

makes sense to me; there are no references to EISCON
on the system other than the include file.

- erik

[Jens Staal]

In my porting of stuff using APE, I often notice that many applications
assume more members of the struct stat in sys/stat.h, especially
st_blocksize. Is there any reasonable similar information available
elsewhere in the system that could be used in a local "rpl_stat" struct for
those ports?

other annoying stuff are normally related to malloc/alloca and sys/mtio.h
stdint.h is normally easily just redirected to inttypes.h and stdbool.h can
also easily included.

Post by Jeff Sickel

Post by Jeff Sickel
I'm not familiar with the full history of /sys/include/ape/errno.h, but

it looks like EISCON should be EISCONN to fit with other systems that at
least pretend to be POSIX compliant. SunOS 5.11 did have EISCON, but...
makes sense to me; there are no references to EISCON
on the system other than the include file.
- erik

[Lyndon Nerenberg]

Post by Jens Staal
In my porting of stuff using APE,

The spec speaks.

[t***@polynum.com]

Post by Jeff Sickel
I'm not familiar with the full history of /sys/include/ape/errno.h, but it looks like EISCON should be EISCONN to fit with other systems that at least pretend to be POSIX compliant. SunOS 5.11 did have EISCON, but...

It should be EISCONN, not because "other systems" have this, but because
it is in Sus v3.

The only reference for APE should be POSIX. One has enough "surprises"
with POSIX support on Unix like systems to not rely upon what they did
or do.

And to verify that a program passes the APE test is a good way to catch
systems idiosynchrasies, BTW...

[Richard Miller]

Post by t***@polynum.com
It should be EISCONN, not because "other systems" have this, but because
it is in Sus v3.

Patch submitted.

[Jeff Sickel]

Post by Richard Miller

Post by t***@polynum.com
It should be EISCONN, not because "other systems" have this, but because
it is in Sus v3.

Other systems were my only reference as I just didn't want to buy the
spec at this stage. If anyone has a link to a freely available spec
then that would be a good reference point for APE in the future.

Post by Richard Miller
Patch submitted.

Thanks for submitting this--I should read the docs and do my own push
in the future.

-jas

[a***@skeeve.com]

Hi.

Post by Jeff Sickel

Post by t***@polynum.com
It should be EISCONN, not because "other systems" have this, but because
it is in Sus v3.

Other systems were my only reference as I just didn't want to buy the
spec at this stage. If anyone has a link to a freely available spec
then that would be a good reference point for APE in the future.

http://pubs.opengroup.org/onlinepubs/009604599/basedefs/errno.h.html

This is from the 2004 standard (the first one google found) but the
2008 version should be findable from opengrouop.org somewhere. It won't
be too much different (we hope! :-).

HTH,

Arnold

[Jeff Sickel]

Post by a***@skeeve.com
http://pubs.opengroup.org/onlinepubs/009604599/basedefs/errno.h.html
This is from the 2004 standard (the first one google found) but the
2008 version should be findable from opengrouop.org somewhere. It won't
be too much different (we hope! :-).

If the OpenGroup's so open why do I need an account to view/download
the Single UNIX Specification? Or any of their specs for that matter...

https://www2.opengroup.org/ogsys/catalog/t101

Guess I'll dig through some other accounts to keep the IEEE lawyers happy.

[a***@skeeve.com]

Hi.

Post by Jeff Sickel

Post by a***@skeeve.com
http://pubs.opengroup.org/onlinepubs/009604599/basedefs/errno.h.html
This is from the 2004 standard (the first one google found) but the
2008 version should be findable from opengrouop.org somewhere. It won't
be too much different (we hope! :-).

If the OpenGroup's so open why do I need an account to view/download
the Single UNIX Specification? Or any of their specs for that matter...
https://www2.opengroup.org/ogsys/catalog/t101
Guess I'll dig through some other accounts to keep the IEEE lawyers happy.

If you're happy with HTML:

http://pubs.opengroup.org/onlinepubs/9699919799/

(Google for "POSIX 2008 base definitions").

HTH,

Arnold

[David du Colombier]

To sum things up a little, here are the different
versions of the Single UNIX Specification, available
from The Open Group:

SUSv2 (1997)
http://www.opengroup.org/onlinepubs/7990989775/

SUSv3 (POSIX.1-2001/2004)
http://www.opengroup.org/onlinepubs/009695399/

SUSv4 (POSIX.1-2008)
http://www.opengroup.org/onlinepubs/9699919799/

[erik quanstrom]

Given all the Plan 9 spinoffs that still include APE, it might
be worth the effort at some point to bring APE up to SUSv3 or
SUSv4 to ease in porting code that's heavily POSIX-dependent.
Though there might not be enough time or energy to take on
such an endeavor.

or even a will to live after the first 10k pages. :-)

- erik

[Jeff Sickel]

Given all the Plan 9 spinoffs that still include APE, it might
be worth the effort at some point to bring APE up to SUSv3 or
SUSv4 to ease in porting code that's heavily POSIX-dependent.

Though there might not be enough time or energy to take on
such an endeavor.

-jas

Post by David du Colombier
To sum things up a little, here are the different
versions of the Single UNIX Specification, available
SUSv2 (1997)
http://www.opengroup.org/onlinepubs/7990989775/
SUSv3 (POSIX.1-2001/2004)
http://www.opengroup.org/onlinepubs/009695399/
SUSv4 (POSIX.1-2008)
http://www.opengroup.org/onlinepubs/9699919799/
--
David du Colombier

[t***@polynum.com]

Given all the Plan 9 spinoffs that still include APE, it might
be worth the effort at some point to bring APE up to SUSv3 or
SUSv4 to ease in porting code that's heavily POSIX-dependent.
Though there might not be enough time or energy to take on
such an endeavor.

YMMV. The problem is not really on the APE side, but---as noted in the
APE paper---that not a lot of programs out there are POSIX compliant.

One can mention the GNU ones, since GNU _is_ "GNU is Not Unix", and
departing from POSIX is a "feature" (I discovered this looooooooonnnng
years ago when I started with GNU/Linux Debian; asking why a POSIX.2
utility like ed(1) was not in the default install, the answer was:
because it is POSIX and GNU blabla, and Perl has everything...)

For kerTeX, I had less problems with APE than with various Unices where
there is always one bit of something that is not as the standard says.

So verifying that the current APE is SuS v3 compliant, for example, but
without extending its scope could be done and rather easily. Trying to
handle various POSIX extensions is more involved and should be done only
if there is a huge need of some external stuff---it could be simpler to
write from scratch a software or to fix the software.

But that's just my opinion ;)

[Jens Staal]

Given all the Plan 9 spinoffs that still include APE, it might
be worth the effort at some point to bring APE up to SUSv3 or
SUSv4 to ease in porting code that's heavily POSIX-dependent.
Though there might not be enough time or energy to take on
such an endeavor.
-jas

Just recently, I copied a few files from the newlib libc into an application
to make it compile under APE.

I guess that the "low road" to take might be to basically do the same but to
generate a temporary "APE extension library" with kernel-independent libc code
copied from other projects (basially similar to what gnulib does).

Newlib and Musl libc are both permissively licensed so they should not be a
problem to use. Musl is currently linux-specific but perhaps there are kernel-
independent parts that could be used. I guess the most important thing is to
make sure that the things included in the extension library does not overlap
with the APE libraries.

The advantage with this approach could be that the real APE keeps clean and
can be developed at its own pace depending on what the needs are (and stuff
found useful from the extension library could be merged back to real APE after
being re-written according to the standards of Plan9).