How to determine available system calls on a Unix/Linux system

[markus]

Hi,

There are more than 1000 defined system calls in the Unix standard
specification, however, a majority of them are optional and the
availability of system calls are dependent on the OS implementation
itself.

The question I have is: How do you determine which system calls are
available on any Unix/Linux machine?

The same question goes for determening available C library functions
on any Unix/Linux machine?

Best regards

 

[Richard Bos]

The question I have is: How do you determine which system calls are
available on any Unix/Linux machine?

The same question goes for determening available C library functions
on any Unix/Linux machine?

If the computer has a conforming C implementation, _all_ C library
functions must be available; otherwise it simply isn't a C
implementation.
As for determining what is present, that's OS-specific, hence off-topic
on comp.lang.c.

Richard

 

[P.T. Breuer]

You don't. It's none of your business. It's the C library's business to
interface between you and the system calls.

But if you wanted to, you would read the kernel's syscall
implementation list in the source code.

If the computer has a conforming C implementation, _all_ C library
functions must be available; otherwise it simply isn't a C
implementation.

Well, whther the functions work or not also enters into it. However ...

As for determining what is present, that's OS-specific, hence off-topic
on comp.lang.c.

In the last 20 years, I have never seen anything that is on topic on
comp.lang.c, which is why I have avoided going there like the plague
during the last 20 years. If you want language lawyery, it's an
excellent place to hang out and pick nits.

It's sort of like Wittgenstein. Anything you asked him he told you was
some other disciplines kind of problem, not philosophy.

Peter

 

[CBFalconer]

There are more than 1000 defined system calls in the Unix standard
specification, however, a majority of them are optional and the
availability of system calls are dependent on the OS implementation
itself.

The question I have is: How do you determine which system calls are
available on any Unix/Linux machine?

The same question goes for determening available C library functions
on any Unix/Linux machine?

ALL the functions specified in the ISO C standard should be
available on any hosted machine. Anything else is system
dependant and off-topic on c.l.c.

Thus code that uses such non-standard calls should be in an
isolated system dependant module, and discussed only on system
specific newsgroups. Above all they should not be cross-posted to
groups where they are OT.

 

[Dan Espen]

Hi,

There are more than 1000 defined system calls in the Unix standard
specification, however, a majority of them are optional and the
availability of system calls are dependent on the OS implementation
itself.

The question I have is: How do you determine which system calls are
available on any Unix/Linux machine?

The same question goes for determening available C library functions
on any Unix/Linux machine?

That is what the "configure" script in most UNIX source code packages
does. If you tell us what you are trying to do, you might get a more
useful answer.

 

[SM Ryan]

(e-mail address removed) (markus) wrote:
# Hi,
#
# There are more than 1000 defined system calls in the Unix standard
# specification, however, a majority of them are optional and the
# availability of system calls are dependent on the OS implementation
# itself.
#
# The question I have is: How do you determine which system calls are
# available on any Unix/Linux machine?

Trial and error, unfortunately, is too often the case. On a proper system you should be
able to look at /usr/share/man/man2 and man3 or the section 2 and 3 portion of xman to
get a rough idea. However many systems anywhere are inadequately documented. You can also
try nm /usr/lib/libc.so or similar files.

 

[Zian Smith]

Hi,

There are more than 1000 defined system calls in the Unix standard
specification, however, a majority of them are optional and the
availability of system calls are dependent on the OS implementation
itself.

The question I have is: How do you determine which system calls are
available on any Unix/Linux machine?

The same question goes for determening available C library functions
on any Unix/Linux machine?

Best regards

you can try
apropos '(3)' for library functions
apropos '(2)' for system calls

This should give you a list, at least for those functions that have a
man page in the system I suppose...

 

[Default User]

P.T. Breuer wrote:

In the last 20 years, I have never seen anything that is on topic on
comp.lang.c, which is why I have avoided going there like the plague
during the last 20 years. If you want language lawyery, it's an
excellent place to hang out and pick nits.

Pure lies. We handle many questions and problems each day, as long as
they fit the topicality of the newsgroup.



Brian Rodenborn

 

[P.T. Breuer]

Pure lies. We handle many questions and problems each day, as long as
they fit the topicality of the newsgroup.

There you are!

Peter

 

[Default User]

There you are!

Quite a non-sequitur. Do you deny that we (comp.lang.c) handle many
questions and problems each day? Do I need to post examples and make
you look foolish?




Brian Rodenborn

 

[Michael Heiming]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

P.T. Breuer wrote:

Quite a non-sequitur. Do you deny that we (comp.lang.c) handle many
questions and problems each day? Do I need to post examples and make
you look foolish?

Mh, looks like both have made their points and seem to have a
quite different opinion about clc. Nothing unusual, or anything
that would make it reasonable to begin insulting each other,
while wasting bandwidth. Probably the only thing a large thread
would change are this weeks stats of colm/cua and clc (if there
is such a thing).

Thx for reading

--
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo (e-mail address removed) | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBTzB+AkPEju3Se5QRAnp4AKCMpv33rr3JD6yK0l2jGDs0FHV1qACgsxTE
8P+pDbYLOjC+WlXKNZELMU0=
=QbXo
-----END PGP SIGNATURE-----

 

[P.T. Breuer]

P.T. Breuer wrote:

Quite a non-sequitur. Do you deny that we (comp.lang.c) handle many
questions and problems each day? Do I need to post examples and make
you look foolish?

!!!!

Yay! They haven't changed!

It's like stepping into a time warp, except I daresay a whole new load
of lusers questons about library functions are nowadays consigned to the
bin of null. Threading anyone? Reentrancy?

Yo ho ho.

Peter

 

[Bill Marcum]

["Followup-To:" header set to comp.unix.admin.]

In the last 20 years, I have never seen anything that is on topic on
comp.lang.c,
which is why I have avoided going there like the plague
during the last 20 years. If you want language lawyery, it's an
excellent place to hang out and pick nits.

If you avoid going to comp.lang.c, you probably only see articles which
are crossposted to that group, and anything crossposted is almost
certain to be considered off-topic.

 

[Default User]

P.T. Breuer wrote:

It's like stepping into a time warp, except I daresay a whole new load
of lusers questons about library functions are nowadays consigned to
the bin of null. Threading anyone? Reentrancy?

You continue to dodge the question. Obviously, you've realized that
your lies are exposed.




Brian Rodenborn

 

[P.T. Breuer]

P.T. Breuer wrote:

You continue to dodge the question. Obviously, you've realized that
your lies are exposed.

Ooooh, yes! It's just as I recalled!

May I go back to arguing on the kernel list now? I really would like to
tell you all about my problems parsing gnu C extensions, but I have an
urgent appointment with a paper clip.

Peter

 

[P.T. Breuer]

If you avoid going to comp.lang.c, you probably only see articles which
are crossposted to that group, and anything crossposted is almost
certain to be considered off-topic.

Hypothetically exactly so. Of course, to all intents and purposes, and
a close approximation that a microbe would say !whew! to, I NEVER see
articles posted to that group, crossposted or not.

Peter

 

[Default User]

May I go back to arguing on the kernel list now? I really would like
to tell you all about my problems parsing gnu C extensions, but I
have an urgent appointment with a paper clip.

Be my guest.

 

[Mark McIntyre]

Hypothetically exactly so. Of course, to all intents and purposes, and
a close approximation that a microbe would say !whew! to, I NEVER see
articles posted to that group, crossposted or not.

It would seem, from the brief exchange I've observed, that you ought to
crawl back under your rock about now, to avoid having your mind polluted
further. Thanks for playing.

 

[P.T. Breuer]

It would seem, from the brief exchange I've observed, that you ought to
crawl back under your rock about now, to avoid having your mind polluted
further. Thanks for playing.

No hay problema - I'm glad to have had my prejudices confirmed! Stay in
the groove, please do!

Peter

 

[Kenny McCormack]

No hay problema - I'm glad to have had my prejudices confirmed! Stay in
the groove, please do!

Peter

You are absolutely right, of course. Now, I'm not saying that problems
don't get solved in this NG, from time to time, although I find it boring
when they do. I much prefer the incessant "OT - that's OT!" postings.

However, the thing is, I can't possibly imagine anything that you could
post to this group, that wouldn't fail at least one of the conditions
below:
1) OT (and we all know what this means by now)
2) Answer findable in some (available online) FAQ or document.
3) Has to do with algorithms. Note that algorithm questions are
generally held to be OT, but there is some leeway here. I think
we would all agree that "How do I do FFTs (in C)?" is OT, but how
about "How do I traverse a string (in C)?"

Note that #2 is a biggie. I'll bet 99.39% of all the advice given here is
available in FAQs and other documents. But it is often easier to just give
the advice, rather than do the technically correct thing - which is to
point the poster at the FAQ/document.