This is the more typical approach used in the tree for system calls
with per-ABI structure layouts.
Obtained from: CheriBSD
Sponsored by: AFRL, DARPA
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 68691 Build 65574: arc lint + arc unit
Event Timeline
| sys/kern/kern_prot.c | ||
|---|---|---|
| 573 | We can't, it gets modified by the function? Oh, you mean the pointer? I mean, we don't generally use that annotation in the kernel (const on pointer values vs const on what the pointer points to), and you can't really change the caller's pointer anyway as it is passed by value. That just means the function promises not to move the pointer I guess? | |
| sys/kern/kern_prot.c | ||
|---|---|---|
| 573 | Yes, the pointer, and yes, as you say, this only means the function promises not to change the pointer itself. Of course, that's a very small improvement that has low but non-zero value, so while it would be silly to impose that as a style matter, I'd like that at least we can still add such annotations while modifying code and keep those that are already in place. | |
| sys/kern/kern_prot.c | ||
|---|---|---|
| 573 | I would have guessed that this had the effect of making the pointer not an array, but that doesn't seem to be true. https://godbolt.org/z/4a3nda6MP In the linked example, i++ is prevented, but you can still access any offset from the pointer so it isn't really doing anything useful. | |
| sys/kern/kern_prot.c | ||
|---|---|---|
| 573 |
It still prevents accidentally changing the pointer itself, via, e.g., = where == is meant, even in cases where no warnings would be emitted, and that is useful. | |
| sys/kern/kern_prot.c | ||
|---|---|---|
| 573 | Modern compilers shout at you out of the box if you do that. Putting const everywhere gets messy very quickly, please don't. | |
| sys/kern/kern_prot.c | ||
|---|---|---|
| 573 |
No, unfortunately, they don't, including in very simple cases (I've tried it, with GCC and clang, -Wall, with and without optimizations, *all* cases fail). And even if they would, that's only one example of mistakes one can do. A variable name mistake in a simple assignment can never be caught. And so on.
This sentence most probably implies that you've been at some point in a hard-to-entangle scenario with lots of const. I can sympathize, but what you experienced simply has nothing to do with what's happening here. Here, there's no const added to some type or field reused elsewhere. Here, there's not even a const to pointed data. There is instead and only a const to a function argument, which by nature is completely local to the function and just an internal contract of it which never propagates to anything. And it's just a single const, not something put everywhere. It would be great if you could overcome your general const detestation and recognize its usefulness (sometimes big, sometimes tiny) in some situations. Now, is keeping a local annotation that was added deliberately, represents a still true assumption and that doesn't cast a shadow to anything else really too much to ask? | |
| sys/kern/kern_prot.c | ||
|---|---|---|
| 573 | [jrtc27@ref16-amd64 ~]$ echo 'int foo(void *p) { if (p = 0) return 1; return 0; }' | clang -x c - -fsyntax-only
<stdin>:1:26: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
1 | int foo(void *p) { if (p = 0) return 1; return 0; }
| ~~^~~
<stdin>:1:26: note: place parentheses around the assignment to silence this warning
1 | int foo(void *p) { if (p = 0) return 1; return 0; }
| ^
| ( )
<stdin>:1:26: note: use '==' to turn this assignment into an equality comparison
1 | int foo(void *p) { if (p = 0) return 1; return 0; }
| ^
| ==
1 warning generated. | |
| sys/kern/kern_prot.c | ||
|---|---|---|
| 573 | You need to play a tiny bit more. $ echo 'int foo(int a, int b) { int c = a = b; return (c); }' | clang -x c - -fsyntax-only $ Oh, and also test it with multiple versions of clang and GCC. | |