OS/2, eCS & ArcaOS - Technical > Programming
Networking: socket() returns positive `non-socket`
Dave Yeo:
So, wondering why the guard around swab in W:\usr\lib\gcc\i686-pc-os2-emx\9\include-fixed\unistd.h fails for you yet the same one in unistd.h works, I thought to download the source.
Rather my sourceforge cookie expired or they've changed their code as all I get is the cloudflare verifying you are human thingy now. Tried on my phone, got something like "downloading to this device is not allowed" in 3 different browsers. Fell back to using Thunderbird, which actually still works. This is a problem on OS/2 as all our browsers fail to get by cloudflare now. Previously I've been asked for help downloading agena due to cloudflare and due to having a cookie, I could.
Next problem, makefile.os2 says https://sourceforge.net/projects/agena/files/Packages/mapmagena-1.1.2a.tar.gz/download is a prerequisite. Sourceforge says it doesn't exist. So using Thunderbird, I found mapmagena-2.0.4.tar.gz in your files area.
I'll try compiling soon.
BTW, Arca Noae does not support GCC and recommends using OpenWatcom, see https://www.arcanoae.com/wiki/information-for-developers/ Most of GCC development is done by Paul now, previously Bitwise who helped Paul and tweaked 9.2.0 and for klibc, originally IBM paid for it to build Mozilla.
KO Myung-Hun:
@agena.info
I have some questions.
1. net_openos2() and net_bindos2() are called in the same process ?
2. What is the result of fstat() in net_bindos2() when returing 'Socket operation on non-socket' error ? And what is the value of (stat.st_mode & S_IFMT) ?
Dave Yeo:
Building agena with makefile.os2 renamed to makefile, so 'make os2' with gcc 9.2.0 dies with,
--- Code: ---make all MYCFLAGS="-O2 -static-libgcc -DLUA_BUILD_AS_DLL -D_FILE_OFFSET_BITS=64 -D_DIRENT_HAVE_D_TYPE -DPCRE2_CODE_UNIT_WIDTH=8 -D__ST_MT_ERRNO__ -DLUA_USE_LINUX -DINCL_BASE -DHAVE_NCURSES_H"
make[1]: Entering directory 'H:/tmp/agena-5.1.1-src/src'
gcc -Wall -Wno-attributes -Wno-strict-aliasing -Wno-deprecated-declarations -Wno-unknown-pragmas -fgnu89-inline -fomit-frame-pointer -DLUA_BUILD_AS_DLL -D_FILE_OFFSET_BITS=64 -D_DIRENT_HAVE_D_TYPE -DPCRE2_CODE_UNIT_WIDTH=8 -D__ST_MT_ERRNO__ -DLUA_USE_LINUX -DINCL_BASE -DHAVE_NCURSES_H -O2 -static-libgcc -DLUA_BUILD_AS_DLL -D_FILE_OFFSET_BITS=64 -D_DIRENT_HAVE_D_TYPE -DPCRE2_CODE_UNIT_WIDTH=8 -D__ST_MT_ERRNO__ -DLUA_USE_LINUX -DINCL_BASE -DHAVE_NCURSES_H -c -o lvm.o lvm.c
In file included from ldo.h:11,
from lvm.h:10,
from lvm.c:24:
lvm.c: In function 'luaV_execute':
lobject.h:217:37: error: incompatible types when assigning to type 'complex double' from type 'lua_Number *' {aka 'double *'}
217 | { TValue *i_o=(obj); i_o->value.c=(x); i_o->tt=LUA_TCOMPLEX; }
| ^
lvm.c:9121:15: note: in expansion of macro 'setcvalue'
9121 | setcvalue(ra, z);
| ^~~~~~~~~
make[1]: *** [<builtin>: lvm.o] Error 1
make[1]: Leaving directory 'H:/tmp/agena-5.1.1-src/src'
make: *** [makefile:117: os2] Error 2
--- End code ---
Similar error with gcc 4.4.6, just less informative.
Need a cast?
Lars:
--- Quote from: agena.info on July 07, 2025, 01:55:49 pm ---1) Have one C function that opens a socket and returns its descriptor, a positive integer, to the Lua environment.
2) Have additional, separate C functions that take the socket descriptor from 1) and that bind, connect, etc.
I guess that as soon as the scope of C function 1) in ArcaOS is left and the interpreter returns to the Lua environment, any info on the socket descriptor is lost and the socket is automatically closed so that all the other functions 2) reject it ?
--- End quote ---
What exactly do you want to say with "the interpreter returns to the Lua environment" ? Your agena.exe code sample is a self-contained executable. I cannot see anything returning to anywhere (granted that the code sample is not complete ...).
I could image that if the "socket" implementation maps socket handles to "virtual" file handles that then handle inheritance and such come into play. That would mean that you will have to know what process or processes access these handles. I have no clue how you would make a socket handle created in process A known to a process B but I suppose that there are ways to do that.
Another thing that I could think of (intentionally or erroneously) is if there is some "tcperrno" variable that might get globally set and that you might have to reset before a call.
I hope that you will only ever get a socket handle >= 3. Because 0 would be for stdin, 1 for stdout and 2 for stderr if we follow the logic that socket handles are mapped to file handles.
Lars:
--- Quote from: Dave Yeo on July 08, 2025, 06:47:11 am ---Building agena with makefile.os2 renamed to makefile, so 'make os2' with gcc 9.2.0 dies with,
--- Code: ---make all MYCFLAGS="-O2 -static-libgcc -DLUA_BUILD_AS_DLL -D_FILE_OFFSET_BITS=64 -D_DIRENT_HAVE_D_TYPE -DPCRE2_CODE_UNIT_WIDTH=8 -D__ST_MT_ERRNO__ -DLUA_USE_LINUX -DINCL_BASE -DHAVE_NCURSES_H"
make[1]: Entering directory 'H:/tmp/agena-5.1.1-src/src'
gcc -Wall -Wno-attributes -Wno-strict-aliasing -Wno-deprecated-declarations -Wno-unknown-pragmas -fgnu89-inline -fomit-frame-pointer -DLUA_BUILD_AS_DLL -D_FILE_OFFSET_BITS=64 -D_DIRENT_HAVE_D_TYPE -DPCRE2_CODE_UNIT_WIDTH=8 -D__ST_MT_ERRNO__ -DLUA_USE_LINUX -DINCL_BASE -DHAVE_NCURSES_H -O2 -static-libgcc -DLUA_BUILD_AS_DLL -D_FILE_OFFSET_BITS=64 -D_DIRENT_HAVE_D_TYPE -DPCRE2_CODE_UNIT_WIDTH=8 -D__ST_MT_ERRNO__ -DLUA_USE_LINUX -DINCL_BASE -DHAVE_NCURSES_H -c -o lvm.o lvm.c
In file included from ldo.h:11,
from lvm.h:10,
from lvm.c:24:
lvm.c: In function 'luaV_execute':
lobject.h:217:37: error: incompatible types when assigning to type 'complex double' from type 'lua_Number *' {aka 'double *'}
217 | { TValue *i_o=(obj); i_o->value.c=(x); i_o->tt=LUA_TCOMPLEX; }
| ^
lvm.c:9121:15: note: in expansion of macro 'setcvalue'
9121 | setcvalue(ra, z);
| ^~~~~~~~~
make[1]: *** [<builtin>: lvm.o] Error 1
make[1]: Leaving directory 'H:/tmp/agena-5.1.1-src/src'
make: *** [makefile:117: os2] Error 2
--- End code ---
Similar error with gcc 4.4.6, just less informative.
Need a cast?
--- End quote ---
I`d try this:
{ TValue *i_o=(obj); i_o->value.c=(*(complex *)(x)); i_o->tt=LUA_TCOMPLEX; }
Looks like the macro is being passed a pointer to double whereas the macro itself uses "complex" which is likely a struct with 2 doubles.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version