From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 7 Dec 2005 15:10:51 +0100 From: =?UTF-8?B?Ik5pbHMgTy4gU2Vsw6VzZGFsIg==?= Subject: Re: [9fans] const In-reply-to: <000401c5fb32$64502e00$14aaa8c0@utelsystems.local> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Message-id: <4396ED6B.9080704@Utel.no> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT References: <000401c5fb32$64502e00$14aaa8c0@utelsystems.local> User-Agent: Thunderbird 1.5 (Windows/20051025) Topicbox-Message-UUID: bc087f06-ead0-11e9-9d60-3106f5b1d025 erik quanstrom wrote: > i've found const pretty useful, dispite the fact it does create some inconsistencies. > it's chief virtue is that you can tell without looking any further than the prototype > that a function that takes a const char* makes it's own copy, if it needs one. > > if you're careful with const, i think it can be a help in preventing some silly mistakes > that will cause a benign looking program to get up and fandango on core. Helps various unixes with (micro?)optimizations as well, which places const data in read only sections which then are normally shared between multiple instances. > unfortunately, glibc, for example, is not very consistant. dispite the fact that it returns > a pointer into envp, glibc getenv is declared as "char* getenv(const char*);". That's exactly how ISO C(99) and posix[1] declares it, I suppose you could blame them. (envp is modifiable on my BSD atleast though. C99 marks it as undefined behavior if you modify it) [1] http://www.opengroup.org/onlinepubs/009695399/functions/getenv.html