Replying inline below... On Sat, Jul 13, 2024 at 3:21 PM Petro Karashchenko < petro.karashche...@gmail.com> wrote:
> Hi, > > This comes more to the edge of coding language paradigms, personal > preferences and readability. > For enable in Rust everything that you define is "const" and if you want to > modify it you should explicitly specify it. On another hand in C everything > you define is modifiable unless you specify "const" to restrict unintended > modification at compile time. This is one of many items that you can find > in discussions why Rust is safer than the C. > > The usage of "const" kind of improves compile time checking, but it adds > more text to the lines and makes code harder to read. Like when I looked > into https://github.com/apache/nuttx/pull/12683 I would maybe remove most > of the "const" there in cases like "const mfs_t depth" or "const struct > mfs_ctz_s new_ctz". But again this comes to personal preferences. > > Personally I'm trying to balance on the edge and inspire from POSIX > sometimes. Of course POSIX could define "read" as "ssize_t read(const int > fildes, void * const buf, const size_t nbyte);", but it is defined as > "ssize_t > read(int fildes, void *buf, size_t nbyte);" that seems to be more readable > while still sacrifice compile time checking. As I'm thinking more about this, I think it makes sense to define read as ssize_t read(int fildes, void * buf, size_t nbyte) and NOT ssize_t read(const int fildes, void * const buf, const size_t nbyte) because of the following reason: specifying const in those places affects what the function implementation can do internally with its stacked copies of those values and address. So if you put those const in the function signature, you would leak an internal implementation detail and you also would prevent alternative implementations that might need to alter those values for the function's use. The only time I would suggest to put those 'const' is when the function is static and part of a module's internal implementation, and is NOT exported to the outside world in the form of an API that has to be maintained forever. More below... This also becomes tricky when "const" may be used "when convenient" like in > "jrnl_rdlog" from https://github.com/apache/nuttx/pull/12683. The > "idx"/"pg" parameters of "jrnl_rdlog" seems also to need "const" like > "const mfs_t depth" from "jrnl_wrlog", but just because author had a > preference not to create a temporary variables "mfs_t tmp_pg = pg;"/"mfs_t > tmp_idx = idx;" and it was "more convenient" to use "idx"/"pg" then const > is omitted in that interface. > > So summarizing, there is no answer of what is the best or what should be > used. > > Note: "const" before or after "*" are ANSI-C compatible, so has nothing to > do with C++ feature enabled in C. Maybe there was something in between > K&R-C and ANSI-C, but that really goes too far back in time. Thinking about how parsing of declarations works in C, it makes sense that const before and after * should have been supported in those early C, though I don't remember it being explicitly documented in K&R's C book. (I originally learned C from K&R's The C Programming Language book and I never heard of const after * until I learned C++.) Cheers Nathan
