Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #6078 > unrolled thread

Return pointers-to-const where data shall not be modified

Back to article view | Back to comp.std.c

Contents

  Return pointers-to-const where data shall not be modified Philipp Klaus Krause <pkk@spth.de> - 2020-05-06 19:25 +0200
    Re: Return pointers-to-const where data shall not be modified Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-06 13:18 -0700
      Re: Return pointers-to-const where data shall not be modified Chris Peterson <cpeterson@mozilla.com> - 2020-08-19 10:44 -0700
        Re: Return pointers-to-const where data shall not be modified Philipp Klaus Krause <pkk@spth.de> - 2020-08-28 11:40 +0200
        Re: Return pointers-to-const where data shall not be modified James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-28 08:42 -0400

#6078 — Return pointers-to-const where data shall not be modified

There are 4 functions (getenv, localeconv, setlocale, strerror) in the
standard library that return a pointer and state that the return value
points to something that "shall not be modified by the program". I
suggest to make these functions return pointers-to-const, e.g.

change

char *strerror(int errnum);

to

const char *strerror(int errnum);

A draft proposal is at
http://www.colecovision.eu/stuff/proposal-const-shall-not-be-modified-stdlib.html

Do you see any problem with this change?

I was wondering if it make sense to also change the char * members of
struct lconf to const char *, but I fear that change might break more stuff.

Philipp

[toc] | [next] | [standalone]

#6082

Philipp Klaus Krause <pkk@spth.de> writes:
> There are 4 functions (getenv, localeconv, setlocale, strerror) in the
> standard library that return a pointer and state that the return value
> points to something that "shall not be modified by the program". I
> suggest to make these functions return pointers-to-const, e.g.
>
> change
>
> char *strerror(int errnum);
>
> to
>
> const char *strerror(int errnum);
>
> A draft proposal is at
> http://www.colecovision.eu/stuff/proposal-const-shall-not-be-modified-stdlib.html

The formatting of the last paragraph on that web page could be improved.

> Do you see any problem with this change?

It would likely break existing code, for the same reason that making
string literals const would break existing code.

Any program that has something like:

    char *username = getenv("USER");

would have to be modified.  That would include any pre-ANSI code that
calls getenv.

(C++ has made some tweaks to some C standard library functions, and it
*could* have modified getenv in this way, but it hasn't.)

> I was wondering if it make sense to also change the char * members of
> struct lconf to const char *, but I fear that change might break more stuff.

I think you mean lconv, and that would likely present the same problem.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#6149

On Wednesday, May 6, 2020 at 1:18:54 PM UTC-7, Keith Thompson wrote:
> Philipp Klaus Krause <p...@spth.de> writes: 
> > There are 4 functions (getenv, localeconv, setlocale, strerror) in the 
> > standard library that return a pointer and state that the return value 
> > points to something that "shall not be modified by the program". I 
> > suggest to make these functions return pointers-to-const, e.g. 
...
> It would likely break existing code, for the same reason that making 
> string literals const would break existing code. 
> 
> Any program that has something like: 
> 
> char *username = getenv("USER"); 
> 
> would have to be modified. That would include any pre-ANSI code that 
> calls getenv. 

Would limiting the const function prototypes to C2x code (gcc -std=c2x) address this concern about backwards compatibility? Old code that wants the non-const function prototypes can ask for an older C version (e.g. gcc -std=c18).

#if __STDC_VERSION__ > 201710L
const char *getenv(const char *name);
#else
char *getenv(const char *name);
#endif

The getenv ABI would be the same for both function prototypes.

[toc] | [prev] | [next] | [standalone]

#6150

Am 19.08.20 um 19:44 schrieb Chris Peterson:
> 
> Would limiting the const function prototypes to C2x code (gcc -std=c2x) address this concern about backwards compatibility? Old code that wants the non-const function prototypes can ask for an older C version (e.g. gcc -std=c18).

That wouldbe done anyway. Changes in the stdandard do not apply
retroactively (from an ISO perspective, the new stadard replaces the old
one, so no statements about older standards are made).

But people (the Austin group, i.e. the POSIX comittee) want to be able
to compile old code in C2X mode and not see any new diagnostics.

Philipp

[toc] | [prev] | [next] | [standalone]

#6151

On 8/19/20 1:44 PM, Chris Peterson wrote:
> On Wednesday, May 6, 2020 at 1:18:54 PM UTC-7, Keith Thompson wrote:
>> Philipp Klaus Krause <p...@spth.de> writes: 
>>> There are 4 functions (getenv, localeconv, setlocale, strerror) in the 
>>> standard library that return a pointer and state that the return value 
>>> points to something that "shall not be modified by the program". I 
>>> suggest to make these functions return pointers-to-const, e.g. 
> ...
>> It would likely break existing code, for the same reason that making 
>> string literals const would break existing code. 
>>
>> Any program that has something like: 
>>
>> char *username = getenv("USER"); 
>>
>> would have to be modified. That would include any pre-ANSI code that 
>> calls getenv. 
> 
> Would limiting the const function prototypes to C2x code (gcc -std=c2x) address this concern about backwards compatibility? Old code that wants the non-const function prototypes can ask for an older C version (e.g. gcc -std=c18).
> 
> #if __STDC_VERSION__ > 201710L
> const char *getenv(const char *name);
> #else
> char *getenv(const char *name);
> #endif

No, backwards compatibility means that code which was correctly written
for an older version of C should, if compiled for a newer version of C
without modification, compile without mandatory diagnostics and with the
same behavior. Maintaining backwards compatibility is only one of
several goals the committee has attempted to achieve when developing new
versions of the C standard. Every version of the standard has had at
least a few cases where backwards compatibility has been sacrificed to
achieve one of the other goals. However, it is one of the most important
such goals.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.std.c

csiph-web