In our previous episode, Ewald said:
> Well, the surprise is that initc worked, and yours not. From a quick glance
> I believe it to be correct too.
I believe there is a bit of confusion:
Ok, cler.
The function that seemingly doesn't work is the native
fpGetErrNo (with native I mean the function that is available in unit
baseunix without any modification).
That only works for routines that call the FPC syscall.do_syscall function directly or indirectly.
Just like cerrno works for functions that call libc functions directly or indirectly.
That's handy, so it would be advisory to use fperrno as much as possible
then.
Use fperrno for FPC predeclared functions. That works.
Show quoted text 5 lines
> fpcerrno is always linking to libc's errno.
>
> On platforms where FPC uses libc to acces the kernel, errno=cerrno.
Thus on linux fpc does its own kernel access then, since errno cerrno?
Yes. Free/Open/NetBSD too. The other *nixes (Haiku,Solaris, Darwin/OSX) fall in the other category.
So, on this linux, after calling a syscall which I defined as `external
'c'`
Not a syscall, but a libc call. Even though it might call a syscall internally.
On most *nixes, the kernel returns the error result in some register. The wrapper code is responsible for properly storing the error result in some variable (and nowdays, preferably in a threadsafe manner)
So libc syscll wrapper code stores in the "c" errno, and routines that call the FPC internal syscall wrapper store it in the RTL errno variable.
(like the madvise in the original post) it makes no sense to call
fpGetErrno, and instead I should call fpgetCerrno to get sensible results?
Correct. Or write madvise out as a true syscall, calling syscall.do_syscall (if there is any). Not all libc calls are direct syscalls.
If the above is right, than errno (without the `C`) contains a leftover
error from somewhere before in the program.
All errno's are not cleared in any way, but should be checked _only_ if a function returns a value that indicates so (usually -1 but sometimes null)
What bothers me is: what (and why) created the contition?
You can't know. Any library call might call several other functions that update errno internally. Schematically, it could be like this:
function somelibccall(aparam:integer):cint;
begin
if aparam=0 then
exit(somefunc(aparam))
else
begin
if aparam>10 then
begin
errno:=einval;
exit(-1);
end;
result:=somefunc2(aparam);
if result=-1 then
begin
result:=somefunc3(aparam+1);
if (result=-1) and (errno=einsomething) then
seterrno(einsomethingelse);
end;
end;
All three somefuncs might write errno, and somelibccall simply passes the result of those calls on (and leaves their error unmodified, except in the last case). Moreover, it can write errno from nowwhere.
In such cases it is impossible to tell what of these cases happened from the result of somelibccall and errno.
