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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 */

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)