Changed content

atomic_add(), atomic_add_value(), atomic_clr(), atomic_clr_value(), atomic_set(), atomic_set_value(), atomic_sub(), atomic_sub_value(), atomic_toggle(), atomic_toggle_value()
Perform atomic operations only on objects that were allocated in normal memory mappings. On certain processors (e.g. some PPC ones), atomic operations will cause a fault if the object is allocated in uncached memory.
calloc(), malloc(), realloc()
The MALLOC_OPTIONS environment variable now controls how these functions behave if you specify a size of 0 (or a value of 0 for the n argument to calloc()). The V ("System V") and R ("use the realloc() behavior of QNX Neutrino 6.4.0 and earlier") columns below indicate how the functions behave if the value of MALLOC_OPTIONS includes that letter:
Function Default V R
calloc(n, 0) Non-NULL NULL No effect
malloc(0) Non-NULL NULL No effect
realloc(NULL, 0) Non-NULL NULL No effect
realloc(non-NULL, 0) Non-NULL NULL NULL

In all the above cases, if the function returns a non-NULL pointer, it's valid only for a corresponding call to free() or realloc().

Note: The default behavior of realloc(non-NULL, 0) has changed in this release. Calls like this used to return NULL.
If a process wants other processes to communicate with it, it typically uses name_attach() to create a channel and associate a name with it, and the sender process uses name_open() to locate that name and create a connection to it.
The High Availability Manager can see death messages only from tasks that are running in session 1, and daemon() doesn't put the caller into that session; use procmgr_daemon() instead if you want to use your application with the HAM.
The description of resolving symbols now includes LD_PRELOAD.
This function now supports the special RTLD_NEXT flag.
fdatasync(), fsync()
These functions block until the given file has been synchronized. For more information about synchronizing, see "Filesystems and block I/O (devb-*) drivers" in the Fine-Tuning Your System chapter of the QNX Neutrino User's Guide.
On a multicore system, the interrupt handler runs on the CPU that takes the interrupt.
On a multicore system, the thread that receives the event set up by InterruptAttachEvent() runs on any CPU, limited only by the scheduler and the runmask.
The integer that's passed to the handler is a combination of the buffer index and the sequence number; to extract each, pass the integer to the _TRACE_GET_BUFFNUM() and _TRACE_GET_BUFFSEQ() macros.
On a multicore system, a thread that calls InterruptWait() runs on any CPU, limited only by the scheduler and the runmask.
We've added more details about the extended (_NOTIFY_CONDE_*) flags.
  • We've documented the following flags:
    • MAP_ELF
    • MAP_FILE — for compatibility; has no effect.
    • MAP_RENAME — for compatibility; has no effect.
    • MAP_NORESERVE — for compatibility; has no effect.
    • MAP_SYSRAM — not a valid bit for mmap().
  • The fildes argument can be the file descriptor for a file, shared memory object, or typed memory object, or NOFD if you're mapping physical memory.
  • If you want to map a device's physical memory, use mmap_device_memory() instead of mmap(); if you want to map a device's registers, use mmap_device_io().
  • The mapping type controls whether or not changes are propagated to the underlying object. With MAP_PRIVATE, changes aren't propagated; with MAP_SHARED they are.
  • You can use MAP_SHARED | MAP_ANON to create a region to be shared by forked applications.
  • If you use MAP_PHYS without MAP_ANON, the offset specifies the exact physical address to map (e.g. for video frame buffers). If you use MAP_PHYS with MAP_ANON, mmap() allocates physically contiguous memory and ignores the offset.
  • We've described how mmap() works with typed memory.
  • When you're mapping a file, you can specify MAP_FILE, but it isn't necessary. We've added an example of mapping a file.
  • You can now create more than one writeable mapping to a file.
We've added more information about the flags member of this structure.
MsgDeliverEvent(), MsgDeliverEvent_r()
These functions can give an error code of EINVAL if the given event isn't valid.
MsgReceivePulsev(), MsgReceivePulsev_r(), MsgReceivev(), MsgReceivev_r(), MsgSendsv(), MsgSendsv_r(), MsgSendsvnc(), MsgSendsvnc_r(), MsgSendv(), MsgSendv_r(), MsgSendvnc(), MsgSendvnc_r(), MsgSendvs(), MsgSendvs_r(), MsgSendvsnc(), MsgSendvsnc_r()
These functions now give an error of EOVERFLOW instead of overflowing a buffer if the sum of the user's IOV lengths exceeds INT_MAX.
This function can indicate an error of EBUSY if it couldn't create a channel.
nanospin(), nanospin_calibrate(), nanospin_count(), nanospin_ns(), nanospin_ns_to_count()
The nanospin*() functions wait for at least the specified time; they might not wait for exactly the specified time. For more information, see the Tick, Tock: Understanding the Neutrino Microkernel's Concept of Time chapter of the QNX Neutrino Programmer's Guide.
pthread_attr_setstackaddr(), pthread_attr_setstacksize()
The system uses some of the provided stack for objects such as thread local storage and an initial stack frame, so less than the entire buffer is available to the thread.
pthread_barrier_init(), pthread_cond_init(), pthread_mutex_init(), pthread_once(), pthread_rwlock_init(), sem_init() SyncTypeCreate(), SyncTypeCreate_r()
You should allocate mutexes, condvars, barriers, reader/writer locks, semaphores, and the control structure for pthread_once() only in normal memory mappings. On certain processors (e.g. some PPC ones), atomic operations such as calls to pthread_mutex_lock() will cause a fault if the control structure is allocated in uncached memory.
When setting the time for use with this function, you can use nsec2timespec() to convert times in nanoseconds to a timespec structure (and timespec2nsec() to convert them back again).
There's a new flag called RESMGR_FLAG_CROSS_ENDIAN that indicates whether the server handles cross-endian support.

The resmgr_attach() function copies the pointers to the resmgr_connect_funcs_t and resmgr_io_funcs_t structures, not the structures themselves. You should allocate the structures, declare them to be static, or make them global variables. If your resource manager is for more than one device with different handlers, create separate structures that define the handlers.

We've described the _RESMGR_DETACH_CLOSE flag, which closes all bindings when detaching.
In QNX Neutrino, RLIMIT_DATA covers all mappings made by the process that are MAP_ANON | MAP_PRIVATE that aren't MAP_STACK, which corresponds typically to heap allocations.
ThreadCtl(), ThreadCtl_r()
These functions indicate an error of EINVAL if the specified runmask is invalid.
Note that pulses are queued for a process, so timer overruns occur only for signals.