Timeline for Linux memcpy restrict keyword syntax
Current License: CC BY-SA 4.0
35 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 25, 2023 at 3:27 | audit | First answers | |||
| Sep 25, 2023 at 8:37 | |||||
| Sep 25, 2023 at 2:57 | audit | First answers | |||
| Sep 25, 2023 at 8:38 | |||||
| Sep 21, 2023 at 15:33 | audit | First answers | |||
| Sep 21, 2023 at 17:46 | |||||
| Sep 20, 2023 at 18:17 | audit | First answers | |||
| Sep 20, 2023 at 18:37 | |||||
| Sep 18, 2023 at 5:32 | audit | First answers | |||
| Sep 18, 2023 at 5:33 | |||||
| Sep 15, 2023 at 10:46 | audit | First answers | |||
| Sep 15, 2023 at 11:24 | |||||
| Sep 13, 2023 at 3:40 | audit | First answers | |||
| Sep 13, 2023 at 8:24 | |||||
| Sep 13, 2023 at 3:35 | audit | First answers | |||
| Sep 13, 2023 at 11:00 | |||||
| Sep 11, 2023 at 13:52 | audit | First answers | |||
| Sep 11, 2023 at 14:57 | |||||
| Sep 9, 2023 at 15:18 | audit | First answers | |||
| Sep 9, 2023 at 15:19 | |||||
| Sep 7, 2023 at 3:17 | audit | First answers | |||
| Sep 7, 2023 at 4:08 | |||||
| Sep 6, 2023 at 19:23 | audit | First answers | |||
| Sep 6, 2023 at 21:30 | |||||
| Sep 6, 2023 at 0:36 | audit | First answers | |||
| Sep 6, 2023 at 7:39 | |||||
| Sep 5, 2023 at 18:00 | audit | First answers | |||
| Sep 5, 2023 at 18:00 | |||||
| Sep 5, 2023 at 16:32 | comment | added | supercat | @WeijunZhou: I don't think there has ever really been a consensus among Committee members as to whether the Standard should seek to define all the constructs programmers might need, or whether it should allow implementations to extend the language to accommodate such needs with the expectation that they will do so. Unfortunately, when there is consensus neither that a construct should be included, or that it should be excluded, the Standard waives jurisdiction without making clear that it's doing so, and some compiler writers interpret that as an intention to forbid the construct. | |
| Sep 5, 2023 at 13:41 | comment | added | Weijun Zhou | For what it's worth, types are required for the parameters list since C23, and K&R syntax like yours will become invalid. However, as they have already gone that far in creating an ad hoc syntax just for the sake of it, it doesn't seem they actually care that much about standard conformity. Also refer to the points in the answer by @JaredoMills. | |
| Sep 5, 2023 at 13:29 | comment | added | Simon Richter |
All this effort thinking about forward declarations, and no one found the obvious solution void *memcpy(dst, src, n) void *[restrict n] dst; void const *[restrict n] src; size_t n; { ... }
|
|
| Sep 5, 2023 at 4:20 | history | edited | Weijun Zhou | CC BY-SA 4.0 |
Grammar
|
| Sep 5, 2023 at 4:19 | vote | accept | tinkerbeast | ||
| Sep 5, 2023 at 2:07 | history | edited | Weijun Zhou | CC BY-SA 4.0 |
Added link to the mailing list itself
|
| Sep 5, 2023 at 2:04 | comment | added | Weijun Zhou |
Fixed. Also replaced all links with those from marc.info.
|
|
| Sep 5, 2023 at 2:02 | history | edited | Weijun Zhou | CC BY-SA 4.0 |
deleted 1 character in body
|
| Sep 5, 2023 at 1:56 | history | edited | Weijun Zhou | CC BY-SA 4.0 |
Use links from MARC
|
| Sep 5, 2023 at 1:47 | history | edited | Weijun Zhou | CC BY-SA 4.0 |
deleted 7 characters in body
|
| Sep 5, 2023 at 1:42 | history | edited | Weijun Zhou | CC BY-SA 4.0 |
deleted 7 characters in body
|
| Sep 5, 2023 at 1:41 | comment | added | Peter Cordes |
The Linux kernel mailing list is a specific mailing list, the LKML, [email protected] . en.wikipedia.org/wiki/Linux_kernel_mailing_list / FAQ: vger.kernel.org/lkml. The list where the discussion took place was the Linux man-pages list. The topic of that mailing list is the Linux man-pages project, not the Linux kernel specifically. It's a Linux mailing list, but not precisely a Linux kernel mailing list. (kernel.org/doc/man-pages/linux-man-ml.html). The fact that it's hosted on kernel.org doesn't make it a Linux kernel mailing list.
|
|
| Sep 5, 2023 at 1:04 | audit | First answers | |||
| Sep 5, 2023 at 1:04 | |||||
| Sep 5, 2023 at 0:52 | history | edited | Weijun Zhou | CC BY-SA 4.0 |
added 9 characters in body
|
| Sep 5, 2023 at 0:47 | comment | added | Weijun Zhou |
Adjusted the wordings. You are right, section 3 are not for syscalls and the original wording is a bit misleading. Still, I think the phrase Linux kernel mailing list is an acceptable description for the mailing list.
|
|
| Sep 5, 2023 at 0:39 | history | edited | Weijun Zhou | CC BY-SA 4.0 |
Section 3 is not kernel syscall documentation
|
| Sep 4, 2023 at 21:27 | comment | added | Peter Cordes |
That's a glibc man page, not the Linux kernel. The memcpy being documented is the one user-space C programs can use in libc.so, not the kernel internals. Some of the Linux manual pages maintained as part of the same project are for system calls, and the glibc wrapper for them, so those man pages will document differences between the library API vs. the raw kernel syscall. e.g. man7.org/linux/man-pages/man2/brk.2.html#NOTES and man7.org/linux/man-pages/man2/clone.2.html#VERSIONS. But others are purely for glibc user-space functions like printf and memcpy.
|
|
| Sep 4, 2023 at 7:43 | history | edited | Weijun Zhou | CC BY-SA 4.0 |
added 5 characters in body
|
| Sep 4, 2023 at 7:35 | history | edited | Weijun Zhou | CC BY-SA 4.0 |
edited body
|
| Sep 4, 2023 at 7:25 | history | edited | Weijun Zhou | CC BY-SA 4.0 |
added 54 characters in body
|
| Sep 4, 2023 at 7:19 | history | answered | Weijun Zhou | CC BY-SA 4.0 |