About This Reference

This preface includes:

What you'll find in this guide
Typographical conventions
Technical support

What you'll find in this guide

The Library Reference describes the C functions, data types, and protocols that are included as part of the QNX Neutrino RTOS.

For information about:	See:
Specific entries	A ¦ B ¦ C ¦ D ¦ E ¦ F ¦ G ¦ H ¦ I ¦ J ¦ K ¦ L ¦ M ¦ N ¦ O ¦ P ¦ Q ¦ R ¦ S ¦ T ¦ U ¦ V ¦ W ¦ X ¦ Y ¦ Z
An overview of what you'll find in each entry	What's in a Function Description?
Descriptions of the manifests that you can use for compile-time changes or inspection	Manifests
The SOCKS package	SOCKS — A Basic Firewall
A summary of functions that are cancellation points, that you can safely call from an interrupt handler, that you can safely call from a signal handler, and that you can't safely call from a multithreaded program.	Summary of Safety Information
Complete safety information	Full Safety Information
Changes to this reference	What's New in This Reference?
Terms used in QNX documentation	Glossary

Some entries in this document refer to undefined behavior. In some cases, such behavior is caused by programming errors (e.g., using conflicting flags) and could cause harm (e.g., memory corruption, the failure of threads to run); in other cases, it consists of implementation details that we don't guarantee and that could change (e.g., the order in which certain things happen). Don't rely on any behavior that you observe in these situations.
Some functions return specific values (e.g., -1) to indicate that an error occurred, but aren't documented as returning specific values for success. You can interpret any other value as success, but don't make any assumptions about specific values. For example, MsgReply() is documented as returning -1 if an error occurred; don't assume that it returns 0 to indicate success. See also “Returns” in the What's in a Function Description? chapter.

For information about programming in Neutrino, see Getting Started with QNX Neutrino: A Guide for Realtime Programmers and the Neutrino Programmer's Guide.

For information about licensing, see:

the QNX Development Suite License Guide at http://licensing.qnx.com/license-guide/
the Third Party License Terms List at http://licensing.qnx.com/third-party-terms/
the matrix of all the versions of all our legal documents at http://licensing.qnx.com/document-archive/

Typographical conventions

Throughout this manual, we use certain typographical conventions to distinguish technical terms. In general, the conventions we use conform to those found in IEEE POSIX publications. The following table summarizes our conventions:

Reference	Example
Code examples	`if( stream == NULL )`
Command options	`-lR`
Commands	`make`
Environment variables	PATH
File and pathnames	`/dev/null`
Function names	exit()
Keyboard chords	Ctrl-Alt-Delete
Keyboard input	`something you type`
Keyboard keys	Enter
Program output	`login:`
Programming constants	NULL
Programming data types	`unsigned short`
Programming literals	`0xFF`, `"message string"`
Variable names	stdin
User-interface components	Cancel

We use an arrow (→) in directions for accessing menu items, like this:

You'll find the Other... menu item under Perspective-->Show View.

We use notes, cautions, and warnings to highlight important messages:

Notes point out something important or useful.

Cautions tell you about commands or procedures that may have unwanted or undesirable side effects.

Warnings tell you about commands or procedures that could be dangerous to your files, your hardware, or even yourself.

Note to Windows users

In our documentation, we use a forward slash (/) as a delimiter in all pathnames, including those pointing to Windows files.

We also generally follow POSIX/UNIX filesystem conventions.

Technical support

To obtain technical support for any QNX product, visit the Support area on our website (www.qnx.com). You'll find a wide range of support options, including community forums.