|
|
Subscribe / Log in / New account

File permissions in the kernel

File permissions in the kernel

Posted Aug 5, 2016 6:35 UTC (Fri) by johill (subscriber, #25196)
In reply to: File permissions in the kernel by epa
Parent article: File permissions in the kernel

It would consume memory in every C file that includes it and even break the link unless it was declared static.


to post comments

File permissions in the kernel

Posted Aug 5, 2016 6:38 UTC (Fri) by johill (subscriber, #25196) [Link] (5 responses)

Oh, wait - const. That doesn't seem to be true then, sorry.

File permissions in the kernel

Posted Aug 5, 2016 6:41 UTC (Fri) by johill (subscriber, #25196) [Link] (4 responses)

Hmm, but looking further, that seems only due to the optimiser, and in fact without the static it does cause build errors. So it's not clear to me whether or not it'll be actually put into every file that doesn't use it, but if you *do* use it then it will consume memory.

File permissions in the kernel

Posted Aug 5, 2016 19:39 UTC (Fri) by xtifr (guest, #143) [Link] (3 responses)

This is one of the subtle differences between C and C++. Stroustrup didn't like the preprocessor, so he declared that a const of a fundamental type (at least) would be inherently inline. It can even participate in constant folding at compile time. He did this specifically so that you could declare consts instead of #defines. C didn't go this route.

In C, if you put "const int foo = 5;" in a header, and include it in multiple files, you'll get a link-time error about multiple definitions. In C++, this not only works, it's preferred.

This is something that can easily trip up a C++ programmer who isn't used to C. C++ books tend to emphasize that #defines are bad and you should use consts instead.

I'm guessing that epa works with C++ more often than with C. :)

File permissions in the kernel

Posted Aug 5, 2016 23:47 UTC (Fri) by Jonno (subscriber, #49613) [Link] (2 responses)

Actually, the only difference between C and C++ in this regards is that in C++, const in the global scope implies static, while in C it doesn't. So C++ "const int = 5;" is equivalent to C and C++ "static const int = 5;", while C "const int = 5" is equivalent to C++ "extern const int = 5;" (which is invalid syntax in standard C, as in C extern can only be used in a declaration and not in a definition). In both C and C++ you would use "extern const int;" to access the non-static constant from a different compilation unit.

File permissions in the kernel

Posted Aug 6, 2016 19:16 UTC (Sat) by xtifr (guest, #143) [Link]

Really? I haven't actually looked that closely.

The difference may be less than you think, though. You can make a pointer to a const int (and this should prevent the compiler from optimizing away the storage), but the same is true of an inline function. The real difference between an inline and a static is that a static will have a separate copy for each translation unit, while an inline will only have one copy for the whole program. (Assuming they aren't all optimized away.)

For normal use (no pointers), the difference won't matter, since the storage will be elided if you turn on even the most basic optimizations (which is pretty normal). And, since you can't modify a const int even with a cast (unless I've just found a bug in g++), the only practical difference would be if you tried to compare two different pointers to what you thought was the same const int. If the const is static, then the comparison *might* fail; if it's inline, it would succeed. But that's not something I've ever done or seen done, so I honestly don't know what the right answer is.

Anyway, I suspect we're drifting a bit off topic, and what you say sounds plausible enough, so I'm certainly not going to contradict you.

File permissions in the kernel

Posted Aug 13, 2016 2:38 UTC (Sat) by thestinger (guest, #91827) [Link]

There are differences. C++ allows a static const to be used in a constant expression, such as defining another static const or using it as a non-variable-length array size.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds