[fpc-devel] Weird output from fpGetErrNo

[Ewald]

Once upon a time, on 01/30/2013 11:34 PM to be precise, Marco van de
Voort said:
>> 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.
Right, I understand.


>> 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.
Yes, of course.


>> (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.
That won't be necessary I think, the `external 'c'` approach (which thus
wraps the syscall up in a c function) is good enough for me. The only
problem I had had to do with the errno, but that was due to me using the
wrong getErrNo function.

>> 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)
That indeed sounds obvious.


>> 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:
>
> [snip]
>   
> 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.
I understand, so there probably is no issue in preceding code then,
which means that I can hereby cross out this issue on my todo-list :-)

Thanks for the help!

-- 
Ewald