1. Forum
  2. Usenet
  3. COMP.STD.C

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

    From Philipp Klaus Krause@21:1/5 to All on Wed May 6 19:25:59 2020
    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)
  • From Keith Thompson@21:1/5 to Philipp Klaus Krause on Wed May 6 13:18:52 2020
    Philipp Klaus Krause <[email protected]> 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) [email protected]
    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)
  • From Chris Peterson@21:1/5 to Keith Thompson on Wed Aug 19 10:44:24 2020
    On Wednesday, May 6, 2020 at 1:18:54 PM UTC-7, Keith Thompson wrote:
    Philipp Klaus Krause <[email protected]> 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)
  • From Philipp Klaus Krause@21:1/5 to All on Fri Aug 28 11:40:44 2020
    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)
  • From James Kuyper@21:1/5 to Chris Peterson on Fri Aug 28 08:42:12 2020
    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 <[email protected]> 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)