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 _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
