View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001968 | 1003.1(2024)/Issue8 | System Interfaces | public | 2026-01-15 09:16 | 2026-01-15 09:16 |
| Reporter | dannyniu | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Omission |
| Status | New | Resolution | Open | ||
| Name | DannyNiu/NJF | ||||
| Organization | Individual | ||||
| User Reference | |||||
| Section | XSH 2.4.3. Signal Actions | ||||
| Page Number | 518-520 | ||||
| Line Number | 18330-18420 | ||||
| Interp Status | |||||
| Final Accepted Text | |||||
| Summary | 0001968: All "pure" functions (including unspecified ones) must be safe with regard to async signals, or no signal handler is. | ||||
| Description | It is common practice in compilers, to generate code using inline functions provided by the runtime that're internal to the implementation, most notably, libgcc_s emit 64-bit arithmetic codes for 32-bit targets. Setting aside the relevance of 32-bit system aside first, the capability of CPUs vary from one architecture to another, so there necessitates these kind of inline stubs on some architecture while not on others. However, the standard currently says: > All other functions (including generic functions) and function-like macros may be unsafe with respect to signals making essentially any code that does anything other than calling async-signal safe functions unsafe. --- I propose that, we define "pure" functions and declare this class of functions safe in signal handlers - typical characteristic of these functions include: 1. their behavior is deterministic with regard to their inputs (and their state should we decide to allow them to keep state), 2. they do not modify the memory of its callers unless a non-const-qualified pointer is explicitly given, 3. any state they keep (should we decide to allow it) are have access semantic that're safe with regard to signals. C23 has introduced 'attributes', some of which are geared towards permitting compiler optimizing calls to "pure" functions, so we can consult their text during word smithing. | ||||
| Desired Action | Consider declaring and defining additional class of "pure" functions as safe with regard to asynchronous signals. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-01-15 09:16 | dannyniu | New Issue |
