Timeline for Is it undefined behaviour to free a `static restrict` array function parameter?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 3, 2025 at 19:17 | answer | added | supercat | timeline score: 0 | |
| Nov 26, 2025 at 6:12 | vote | accept | ais523 | ||
| Nov 25, 2025 at 17:12 | comment | added | Ian Abbott | @ais523 N3299 is actually pretty close to the 2024 standard, even though it is a C2y draft. I had a go at converting N3299 to ISO/IEC 9899:2024 a few months ago. See my ISO/IEC JTC1/SC22/WG14 document N3299 to ISO/IEC 9899:2024 (en) conversion. | |
| Nov 25, 2025 at 14:46 | comment | added | Eric Postpischil |
Re "restrict means that memory accessed through the restrict pointer isn't accessed any other way during the function body": Not quite. That only applies if the memory is modified in any way. If all accesses are reads, restrict does not impose any requirements.
|
|
| Nov 25, 2025 at 14:45 | answer | added | Eric Postpischil | timeline score: 5 | |
| Nov 25, 2025 at 14:30 | comment | added | ais523 | @EricPostpischil: you're right, I'm using a draft (specifically N3299) because I don't have access to the official version. I didn't realise that it had diverged so much (previous drafts were pretty close to the standard). | |
| Nov 25, 2025 at 14:25 | comment | added | Eric Postpischil | @ais523: Your references to paragraph numbers suggest you are using an unofficial draft of the C standard. The official 2024 C standard does not contain paragraph numbers. You should be aware that, unlike prior versions of the standard, there are considerable differences between the committee’s last draft and the official C standard. (It changed in some post-committee balloting process I have little information about.) So it is preferable to use the official standard and not drafts and, when using a draft, to explicitly state that and cite the draft version. | |
| Nov 25, 2025 at 14:09 | comment | added | ais523 |
@Lundin: 6.7.4.2p4 is ambiguous, and I agree that on its own, its second half could be interpreted to ban any assignment of one restrict pointer to another (not just assignments after initialization). However, 6.7.4.2p11 seems to clariify that the rule only applies to assignments that occur after the pointer initially gains its value (and specifically states that the case of passing a restrict pointer to a function that takes a restrict pointer as argument is legal).
|
|
| Nov 25, 2025 at 13:57 | comment | added | Lundin |
I think it is UB to assign a restrict pointer to another restrict pointer in the same scope - passing arguments to a function is done as per assignment. This is about a muddy fiasco chapter of ISO C called "formal definition of restrict" (C23 6.7.4.2).
|
|
| Nov 25, 2025 at 13:40 | history | asked | ais523 | CC BY-SA 4.0 |