[fpc-devel] Fpsigprocmask

Marco van de Voort marcov at stack.nl
Tue Jan 26 15:00:58 CET 2010

In our previous episode, Michael Schnell said:

> On 01/26/2010 01:32 PM, Jonas Maebe wrote:
> > I think that you are confusing two things:
> > a) using the libc unit is always bad (except for keeping old Kylix code running on Linux/i386)
> > b) the C *library* is perfectly fine to depend on for stuff like this

> Of course you are right that I am confused with that.
> So using syncobj is "allowed" as same encapsulates the libc.so calls in
> a "compatible" way.
> also using basunix and friends is "allowed" as same encapsulates the
> libc.so calls in a "compatible" way.

Rougly correct. But the geenral idea is that the FPC RTL tries to abstract
calls and typing in a portable, supportable way. In short, you don't need to
know what is beneath them, as long as it works.

For some functionality libc is used, for some not, and this exact
implementation might differ according to platform, and might change over

Certain complex, risky kinds of calls (like dynamic library loading,
threading, locale and user authentication) are generally implemented via
libc and iconv.

Some more general ones (baseunix, unix,IPC, termio) can be syscalls or
libc.so based, depending on the nature of the target, or the target
maintainer's choice.

In general the idea is that if you need unit libc or declare your own
exports to libc, you are doing something atypical. That can be because you 
really are atypical (e.g. in the case of extreme requirements or deep OS
dependant system interfacing), but more generally you are doing something

See also

More information about the fpc-devel mailing list