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

Groups > comp.lang.c > #387229 > unrolled thread

relearning C: why does an in-place change to a char* segfault?

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

Contents

  relearning C: why does an in-place change to a char* segfault? Mark Summerfield <mark@qtrac.eu> - 2024-08-01 08:06 +0000
    Re: relearning C: why does an in-place change to a char* segfault? Mark Summerfield <mark@qtrac.eu> - 2024-08-01 08:24 +0000
      Re: relearning C: why does an in-place change to a char* segfault? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-01 11:53 +0100
    Re: relearning C: why does an in-place change to a char* segfault? Richard Harnden <richard.nospam@gmail.invalid> - 2024-08-01 09:38 +0100
      Re: relearning C: why does an in-place change to a char* segfault? Mark Summerfield <mark@qtrac.eu> - 2024-08-01 08:54 +0000
      Re: relearning C: why does an in-place change to a char* segfault? Bart <bc@freeuk.com> - 2024-08-01 11:12 +0100
        Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-01 13:59 -0700
          Re: relearning C: why does an in-place change to a char* segfault? Bart <bc@freeuk.com> - 2024-08-01 22:07 +0100
            Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-01 14:28 -0700
            Re: relearning C: why does an in-place change to a char* segfault? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-01 20:20 -0400
            Re: relearning C: why does an in-place change to a char* segfault? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-02 01:06 +0000
              Re: relearning C: why does an in-place change to a char* segfault? Bart <bc@freeuk.com> - 2024-08-02 10:43 +0100
                Re: relearning C: why does an in-place change to a char* segfault? Richard Damon <richard@damon-family.org> - 2024-08-02 11:03 -0400
                Re: relearning C: why does an in-place change to a char* segfault? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-02 14:19 -0400
                  Re: relearning C: why does an in-place change to a char* segfault? Bart <bc@freeuk.com> - 2024-08-02 19:33 +0100
                  Re: relearning C: why does an in-place change to a char* segfault? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-03 01:31 +0000
                    Re: relearning C: why does an in-place change to a char* segfault? Richard Damon <richard@damon-family.org> - 2024-08-02 22:01 -0400
                      Re: relearning C: why does an in-place change to a char* segfault? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2024-08-03 08:32 -0600
                      Re: relearning C: why does an in-place change to a char* segfault? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-04 01:05 +0000
                      Re: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 02:52 -0700
                  Re: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-13 17:46 -0700
                    Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-13 18:44 -0700
                      Re: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-15 16:00 -0700
                        Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-15 16:27 -0700
                          Re: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-27 17:33 -0700
                            Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-27 20:34 -0700
                              Re: relearning C: why does an in-place change to a char* segfault? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-28 07:22 +0200
                                Re: relearning C: why does an in-place change to a char* segfault? Phillip Frabott <nntp@fulltermprivacy.com> - 2024-09-28 17:57 +0000
                                  Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-28 13:42 -0700
                                    Re: relearning C: why does an in-place change to a char* segfault? Phillip Frabott <nntp@fulltermprivacy.com> - 2024-09-28 22:05 +0000
                                      Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-28 15:17 -0700
                    Re: relearning C: why does an in-place change to a char* segfault? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-14 10:33 -0400
                      Re: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-15 16:05 -0700
            Re: relearning C: why does an in-place change to a char* segfault? Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-04 15:52 +0200
          Re: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 14:11 -0700
            Re: relearning C: why does an in-place change to a char* segfault? Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-13 15:34 +0100
              Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-13 13:08 -0700
                Re: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-13 17:41 -0700
                Re: relearning C: why does an in-place change to a char* segfault? David Brown <david.brown@hesbynett.no> - 2024-08-14 10:40 +0200
              Re: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-13 17:40 -0700
                Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-13 18:47 -0700
                  Re: relearning C: why does an in-place change to a char* segfault? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-14 03:16 +0000
                    Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-13 20:49 -0700
    Re: relearning C: why does an in-place change to a char* segfault? scott@slp53.sl.home (Scott Lurndal) - 2024-08-01 13:28 +0000
    No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Michael S <already5chosen@yahoo.com> - 2024-08-01 17:40 +0300
      Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? David Brown <david.brown@hesbynett.no> - 2024-08-01 19:56 +0200
        Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-08-02 05:30 +0000
          Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-02 03:02 -0700
            Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Richard Harnden <richard.nospam@gmail.invalid> - 2024-08-02 13:04 +0100
              Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-02 09:59 -0400
              Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-02 11:24 -0700
                Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Richard Damon <richard@damon-family.org> - 2024-08-02 14:42 -0400
                  Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-02 14:58 -0400
                    Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Richard Damon <richard@damon-family.org> - 2024-08-02 15:11 -0400
                      Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 08:32 -0700
                  Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 08:27 -0700
                Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-08-02 12:27 -0700
                  Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-02 23:29 +0100
                    Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-08-02 16:11 -0700
                      Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-05 02:06 +0100
                        Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-08-04 19:37 -0700
                          Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-08-04 19:38 -0700
                          Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-05 12:03 +0100
                            Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-08-05 13:35 -0700
                              Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-05 21:54 +0100
                                Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-08-05 15:39 -0700
                                  Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-06 12:29 +0100
                                    Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-08-06 12:48 -0700
                                      Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-06 23:59 +0100
                                        Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-08-12 16:18 -0700
                                Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-08-05 15:44 -0700
                Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 14:38 -0700
                  Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-12 14:55 -0700
                    Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-03 06:11 -0700
              Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? dave_thompson_2@comcast.net - 2024-08-25 16:52 -0400
                Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-25 14:26 -0700
            Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 14:33 -0700
              Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-12 14:45 -0700
                Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 16:05 -0700
                  Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? David Brown <david.brown@hesbynett.no> - 2024-08-13 13:08 +0200
                    Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-13 13:00 -0700
          Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault? David Brown <david.brown@hesbynett.no> - 2024-08-03 19:54 +0200
    Re: relearning C: why does an in-place change to a char* segfault? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-01 12:02 -0400
    Re: relearning C: why does an in-place change to a char* segfault? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-01 19:39 +0000
      Re: relearning C: why does an in-place change to a char* segfault? Bart <bc@freeuk.com> - 2024-08-01 21:42 +0100
        Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-01 14:13 -0700
        Re: relearning C: why does an in-place change to a char* segfault? Ben Bacarisse <ben@bsb.me.uk> - 2024-08-01 22:40 +0100
        Re: relearning C: why does an in-place change to a char* segfault? Kaz Kylheku <643-408-1753@kylheku.com> - 2024-08-02 00:37 +0000
          Re: relearning C: why does an in-place change to a char* segfault? Bart <bc@freeuk.com> - 2024-08-02 11:36 +0100
          Re: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 13:47 -0700
        Re: relearning C: why does an in-place change to a char* segfault? David Brown <david.brown@hesbynett.no> - 2024-08-03 00:14 +0200
          Re: relearning C: why does an in-place change to a char* segfault? scott@slp53.sl.home (Scott Lurndal) - 2024-08-03 17:07 +0000
            Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-03 17:11 -0700
          Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-03 17:07 -0700
            Re: relearning C: why does an in-place change to a char* segfault? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-04 01:08 +0000
              Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-03 19:58 -0700
                Re: relearning C: why does an in-place change to a char* segfault? Richard Damon <richard@damon-family.org> - 2024-08-04 07:22 -0400
                  Re: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 02:55 -0700
                Re: relearning C: why does an in-place change to a char* segfault? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-05 06:33 +0000
                  Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-04 23:38 -0700
                    Re: relearning C: why does an in-place change to a char* segfault? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-05 21:27 +0000
                      Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-05 15:40 -0700
                        Re: relearning C: why does an in-place change to a char* segfault? Bart <bc@freeuk.com> - 2024-08-06 16:57 +0100
                          Re: relearning C: why does an in-place change to a char* segfault? David Brown <david.brown@hesbynett.no> - 2024-08-06 20:40 +0200
            Re: relearning C: why does an in-place change to a char* segfault? David Brown <david.brown@hesbynett.no> - 2024-08-04 17:20 +0200
      Re: relearning C: why does an in-place change to a char* segfault? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-01 14:06 -0700
      Re: relearning C: why does an in-place change to a char* segfault? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-13 17:43 -0700

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#387557

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> Just as 1 is an integer literal whose value cannot be modified,
> [...]

The C language doesn't have integer literals.  C has string
literals, and compound literals, and it has integer constants.
But C does not have integer literals.

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

#387558

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> Just as 1 is an integer literal whose value cannot be modified,
>> [...]
>
> The C language doesn't have integer literals.  C has string
> literals, and compound literals, and it has integer constants.
> But C does not have integer literals.

Technically correct (but IMHO not really worth worrying about).

There is a proposal for C2y, authored by Jens Gustedt, to change the
term "constant" to "literal" for character, integer, and floating
constants.  (I think it's a good idea.)

<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3239.htm>

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#387591

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>
>>> Just as 1 is an integer literal whose value cannot be modified,
>>> [...]
>>
>> The C language doesn't have integer literals.  C has string
>> literals, and compound literals, and it has integer constants.
>> But C does not have integer literals.
>
> Technically correct (but IMHO not really worth worrying about).

Anyone who flogs others posters for incorrectly using terminology
defined in the ISO C standard should set a good example by using
the ISO-C-defined terms correctly himself.

> There is a proposal for C2y, authored by Jens Gustedt, to change the
> term "constant" to "literal" for character, integer, and floating
> constants.  (I think it's a good idea.)
>
> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3239.htm>

The more C is changed to resemble C++ the worse it becomes.  It
isn't surprising that you like it.

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

#387593

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>
>>>> Just as 1 is an integer literal whose value cannot be modified,
>>>> [...]
>>>
>>> The C language doesn't have integer literals.  C has string
>>> literals, and compound literals, and it has integer constants.
>>> But C does not have integer literals.
>>
>> Technically correct (but IMHO not really worth worrying about).
>
> Anyone who flogs others posters for incorrectly using terminology
> defined in the ISO C standard should set a good example by using
> the ISO-C-defined terms correctly himself.

In fact I do.  In my own writing, I use the term "integer constant",
not "integer literal", when discussing C.  (It's likely I haven't
been 100% consistent.)

My point is that, while "integer literal" is inconsistent with the
terminology used in the C standard, it is not ambiguous or confusing.

C does not define the term "literal" (it defines the phrases "string
literal" and "compound literal").  The word "literal" by itself
is a very common term used when discussing programs in general.
When I looked into it last time this came up, I found that most of
the programming languages I looked into refer to 42 as a literal,
not as a constant.

I'll also note that the word "constant" is overloaded in C.
For example, as of C17, the description of "sizeof" says: "If the
type of the operand is a variable length array type, the operand
is evaluated; otherwise, the operand is not evaluated and the
result is an integer constant."  Though the meaning is clear,
it's an incorrect usage.  (C23 changes this to "... and the result
is an integer constant expression", which is better, but it's the
expression, not its result, that is an integer constant expression.)

Replacing the term "constant" by "literal" would, in my opinion,
improve the clarity of the standard.  I see no drawbacks to such
a change (other than the overhead of *any* change to the standard).

>> There is a proposal for C2y, authored by Jens Gustedt, to change the
>> term "constant" to "literal" for character, integer, and floating
>> constants.  (I think it's a good idea.)
>>
>> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3239.htm>
>
> The more C is changed to resemble C++ the worse it becomes.  It
> isn't surprising that you like it.

I presume that was intended as a personal insult.  I urge you to do
better.

I acknowledge your opinion.  I do not share it.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#388535

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

>> The more C is changed to resemble C++ the worse it becomes.  It
>> isn't surprising that you like it.
>
> I presume that was intended as a personal insult.

It wasn't.

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

#388536

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> The more C is changed to resemble C++ the worse it becomes.  It
>>> isn't surprising that you like it.
>>
>> I presume that was intended as a personal insult.
>
> It wasn't.

Then you need to work on knowing when you've insulted someone.

For context, since the parent article is from a month and a half
ago, I was discussing a proposal to change a future C standard to
refer to "constants" as "literals".  I mentioned that I think it's
a good idea.

In response, you wrote the above.  The implication is that you
expect me to like ideas that make C worse.  At the time, I took
that as a clear insult.  Thinking about it now, I can only take
your word that it wasn't your intent, but I still don't see how it
could be anything other than a clear insult.

I've considered asking for an explanation, but I don't feel the
need to discuss this further.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#388538

On 28.09.2024 05:34, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> The more C is changed to resemble C++ the worse it becomes.  It
>>>> isn't surprising that you like it.
> 
> For context, since the parent article is from a month and a half
> ago, I was discussing a proposal to change a future C standard to
> refer to "constants" as "literals".  I mentioned that I think it's
> a good idea.

I've heard of and seen various forms to name such entities...
- in a Pascal and an Eiffel book I find all these named "constants"
- in an Algol 68 book I read about "standard designations"
- in a book about languages and programming in general I find
    "literals" ("abc"), "numerals" (42), "word-symbols" (false),
    "graphemes" (©), etc., differentiated
- I've also have heard about "standard representations [for the
    values of a respective type]"; also a type-independent term

I also think (for various reasons) that "constants" is not a good
term. (Personally I like terms like the Algol 68 term, that seems
to "operate" on another [more conceptual] abstraction level.)

But you'll certainly have to expect a lot of anger if the terminology
of some standards documents get changed from one version to another.

Janis

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

#388541

In reply to "Janis Papanagnou" who wrote the following:

> On 28.09.2024 05:34, Keith Thompson wrote:
> > Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> > > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> > > > > The more C is changed to resemble C++ the worse it becomes.  It
> > > > > isn't surprising that you like it.
> > 
> > For context, since the parent article is from a month and a half
> > ago, I was discussing a proposal to change a future C standard to
> > refer to "constants" as "literals".  I mentioned that I think it's
> > a good idea.
> 
> I've heard of and seen various forms to name such entities...
> - in a Pascal and an Eiffel book I find all these named "constants"
> - in an Algol 68 book I read about "standard designations"
> - in a book about languages and programming in general I find
>     "literals" ("abc"), "numerals" (42), "word-symbols" (false),
>     "graphemes" (©), etc., differentiated
> - I've also have heard about "standard representations [for the
>     values of a respective type]"; also a type-independent term
> 
> I also think (for various reasons) that "constants" is not a good
> term. (Personally I like terms like the Algol 68 term, that seems
> to "operate" on another [more conceptual] abstraction level.)
> 
> But you'll certainly have to expect a lot of anger if the terminology
> of some standards documents get changed from one version to another.
> 
> Janis


The only gripe I would have if we synonymized constants and literals is that not 
every const is initialized with a literal. There have been times where I have 
initialized a const from the value of a variable. I don't think that const and 
literals are the same thing because of this.

To me a const is permanently set at initialization. That being runtime while a 
literal is a hardcoded value that gets set at compile time.

There are cases where it does in fact matter, especially when a const is not 
initialized with a literal but a var. It can also make a bigger difference when 
someone actually needs to know when something is being set at compile time and 
when it is being set at runtime. It can have a huge impact especially in edge 
cases.

But thats just my 2 cents in the mix.

Have a good one!

Phillip Frabott
{Adam: Is a void really a void if it returns? - Jack: No, it's just nullspace at 
that point.}
Phillip Frabott
{Adam: Is a void really a void if it returns? - Jack: No, it's just nullspace at 
that point.}


-- 
----------------------------------------- --- -- -
Posted with NewsLeecher v7.0 Final
Free Newsreader @ http://www.newsleecher.com/
------------------------------- ----- ---- -- -

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

#388544

Phillip Frabott <nntp@fulltermprivacy.com> writes:
> In reply to "Janis Papanagnou" who wrote the following:
[...]
>> I also think (for various reasons) that "constants" is not a good
>> term. (Personally I like terms like the Algol 68 term, that seems
>> to "operate" on another [more conceptual] abstraction level.)
>> 
>> But you'll certainly have to expect a lot of anger if the terminology
>> of some standards documents get changed from one version to another.
>
> The only gripe I would have if we synonymized constants and literals
> is that not every const is initialized with a literal. There have been
> times where I have initialized a const from the value of a variable. I
> don't think that const and literals are the same thing because of
> this.

Though the word "const" is obviously derived from the English word
"constant", in C "const" and "constant" are very different things.

The "const" keyword really means "read-only" (and perhaps would have
been clearer if it had been spelled "readonly").

A "constant" is what some languages call a "literal", and a "constant
expression" is an expression that can be evaluated at compile time.

For example, this:

    const int r = rand();

is perfectly valid.

Incidentally, the N3301 draft of the C2Y standard has this change
applied to it:

    Syntax
        constant:
            integer-literal
            floating-literal
            enumeration-constant
            character-literal
            predefined-constant

The predefined constants are false, true, and nullptr.

(I find it a bit odd that enumeration and predefined constants are still
called constants, not literals.)

Compare C17:

    Syntax
        constant:
            integer-constant
            floating-constant
            enumeration-constant
            character-constant


https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3301.pdf
(open-std.org seems to be down at the moment.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#388545

In reply to "Keith Thompson" who wrote the following:

> Phillip Frabott <nntp@fulltermprivacy.com> writes:
> > In reply to "Janis Papanagnou" who wrote the following:
> [...]
> > > I also think (for various reasons) that "constants" is not a good
> > > term. (Personally I like terms like the Algol 68 term, that seems
> > > to "operate" on another [more conceptual] abstraction level.)
> > > 
> > > But you'll certainly have to expect a lot of anger if the terminology
> > > of some standards documents get changed from one version to another.
> > 
> > The only gripe I would have if we synonymized constants and literals
> > is that not every const is initialized with a literal. There have been
> > times where I have initialized a const from the value of a variable. I
> > don't think that const and literals are the same thing because of
> > this.
> 
> Though the word "const" is obviously derived from the English word
> "constant", in C "const" and "constant" are very different things.
> 
> The "const" keyword really means "read-only" (and perhaps would have
> been clearer if it had been spelled "readonly").

In the context of C I agree. Although I would point out that for some langauges 
const and readonly are two completely different things. (just a brevity remark, 
but I'll get back on topic now)

> A "constant" is what some languages call a "literal", and a "constant
> expression" is an expression that can be evaluated at compile time.
> 
> For example, this:
> 
>     const int r = rand();
> 
> is perfectly valid.

Maybe the expression can be determined/evaluated at compile time but not the 
result. When I think of literals the resulting value has to be determined at 
compile time. So const int r = 15; would be to me a literal result. The compiler 
can bake that in without needing further runtime execution to get such result. 
But a const can be either a literal or non-literal in my view. Anything that 
cannot give a predetermined value at compile time is a const. So to me:

const int r = rand();

is not a literal only because the output of rand() is unknown until runtime. 
From a human-readable code perspective I get it. And fine, there can be a 
similarity between const and literal on the surface. But the moment you need to 
know exactly what the compiler is doing, those two things have to be separate.

Perhaps there is a better way to do it. Or maybe there can be a literal type 
that is basically equal to const type for the purpose of coding or even perhaps 
a [--treat-const-as-literal] compiler parameter for code where a literal value 
and a const value should be treated the same. But I still think these two should 
be treated differently.

I should note I don't have the original posting for this thread (I guess my 
provider doesn't have it) so I don't have the original URI that started this 
thread. If someone can share it in a reply I'd really appreciate it so I can be 
sure I'm on the same page with what is being discussed.
Phillip Frabott
{Adam: Is a void really a void if it returns? - Jack: No, it's just nullspace at 
that point.}


-- 
----------------------------------------- --- -- -
Posted with NewsLeecher v7.0 Final
Free Newsreader @ http://www.newsleecher.com/
------------------------------- ----- ---- -- -

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

#388546

Phillip Frabott <nntp@fulltermprivacy.com> writes:
> In reply to "Keith Thompson" who wrote the following:
>> Phillip Frabott <nntp@fulltermprivacy.com> writes:
>> > In reply to "Janis Papanagnou" who wrote the following:
>> [...]
>> > > I also think (for various reasons) that "constants" is not a good
>> > > term. (Personally I like terms like the Algol 68 term, that seems
>> > > to "operate" on another [more conceptual] abstraction level.)
>> > > 
>> > > But you'll certainly have to expect a lot of anger if the terminology
>> > > of some standards documents get changed from one version to another.
>> > 
>> > The only gripe I would have if we synonymized constants and literals
>> > is that not every const is initialized with a literal. There have been
>> > times where I have initialized a const from the value of a variable. I
>> > don't think that const and literals are the same thing because of
>> > this.
>> 
>> Though the word "const" is obviously derived from the English word
>> "constant", in C "const" and "constant" are very different things.
>> 
>> The "const" keyword really means "read-only" (and perhaps would have
>> been clearer if it had been spelled "readonly").
>
> In the context of C I agree. Although I would point out that for some langauges 
> const and readonly are two completely different things. (just a brevity remark, 
> but I'll get back on topic now)
>
>> A "constant" is what some languages call a "literal", and a "constant
>> expression" is an expression that can be evaluated at compile time.
>> 
>> For example, this:
>> 
>>     const int r = rand();
>> 
>> is perfectly valid.
>
> Maybe the expression can be determined/evaluated at compile time but not the 
> result. When I think of literals the resulting value has to be determined at 
> compile time. So const int r = 15; would be to me a literal result. The compiler 
> can bake that in without needing further runtime execution to get such result. 
> But a const can be either a literal or non-literal in my view. Anything that 
> cannot give a predetermined value at compile time is a const. So to me:
>
> const int r = rand();
>
> is not a literal only because the output of rand() is unknown until
> runtime.

Of course that's not a literal, nor is it constant.  The object r is
*const* (its value cannot be changed after its initialization), not
*constant*.

> From a human-readable code perspective I get it. And fine, there can be a 
> similarity between const and literal on the surface. But the moment you need to 
> know exactly what the compiler is doing, those two things have to be separate.

Certainly "const" and "literal" are separate.  They mean almost
completely different things.

I can't help wondering if you missed the point.

A literal, as the term is commonly used, is a single token that
represents a constant (compile-time) value of some type.  Examples are
42 and "foo".  (C compound literals are more complicated.)

C uses the term "constant" (as a noun) for tokens of numeric types, like
42 and 1.5, that represent compile-time values.  C2Y will likely refer
to these as "literals".  See
    https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3239.htm
which is the proposal to use the word "literal", and
    https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3301.pdf
particularly section 6.4.5, which is a C2Y draft that incorporates the
proposal (when open-std.org is up and running again).

The word "constant" is also used as an adjective in the phrase "constant
expression".  A constant expression,  like (2+2), is one that's required
to be evaluated at compile time in certain contexts, so it can't refer
to the value of a variable.

The keyword "const" is almost unrelated to either "const" or "literal".
It means that an object cannot legally be modified after it's been
initialized.

The planned change for C2Y is to use the word "literal" rather than
"constant".  There's no change to the phrase "constant expression".

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#387567

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> Just as 1 is an integer literal whose value cannot be modified,
>> [...]
>
> The C language doesn't have integer literals.  C has string
> literals, and compound literals, and it has integer constants.
> But C does not have integer literals.

True, but C++ does, and it means the same thing by "integer literal"
that C means by "integer constant". C doesn't define the term "integer
literal" with any conflicting meaning, and my use of the C++ terminology
allowed me to make the parallel with string literals clearer, so I don't
see any particular problem with my choice of words.

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

#387592

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>
>>> Just as 1 is an integer literal whose value cannot be modified,
>>> [...]
>>
>> The C language doesn't have integer literals.  C has string
>> literals, and compound literals, and it has integer constants.
>> But C does not have integer literals.
>
> True, but C++ does, and it means the same thing by "integer literal"
> that C means by "integer constant".

This is comp.lang.c, not comp.lang.c++.  You flog Bart for using
C-standard-defined terms wrongly.  This case is no different.

> C doesn't define the term "integer
> literal" with any conflicting meaning, and my use of the C++ terminology
> allowed me to make the parallel with string literals clearer, so I don't
> see any particular problem with my choice of words.

In this case you are in the wrong.  Just be a man and admit it.  Oh, I
forgot, your rhetorical religion doesn't allow you to admit any
linguistic imperfection, so you try to sleaze your way to a different
subject so you can continue to argue.

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

#387323

Am 01.08.2024 um 23:07 schrieb Bart:
> On 01/08/2024 21:59, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 01/08/2024 09:38, Richard Harnden wrote:
>>>> On 01/08/2024 09:06, Mark Summerfield wrote:
>>>>> This program segfaults at the commented line:
>>>>>
>>>>> #include <ctype.h>
>>>>> #include <stdio.h>
>>>>>
>>>>> void uppercase_ascii(char *s) {
>>>>>       while (*s) {
>>>>>           *s = toupper(*s); // SEGFAULT
>>>>>           s++;
>>>>>       }
>>>>> }
>>>>>
>>>>> int main() {
>>>>>       char* text = "this is a test";
>>>>>       printf("before [%s]\n", text);
>>>>>       uppercase_ascii(text);
>>>>>       printf("after  [%s]\n", text);
>>>>> }
>>>> text is pointing to "this is a test" - and that is stored in the
>>>> program binary and that's why can't modify it.
>>>
>>> That's not the reason for the segfault in this case.
>>
>> I'm fairly sure it is.
>>
>>>                                                       With some
>>> compilers, you *can* modify it, but that will permanently modify that
>>> string constant. (If the code is repeated, the text is already in
>>> capitals the second time around.)
>>>
>>> It segfaults when the string is stored in a read-only part of the 
>>> binary.
>>
>> A string literal creates an array object with static storage duration.
>> Any attempt to modify that array object has undefined behavior.
> 
> What's the difference between such an object, and an array like one of 
> these:
> 
>   static char A[100];
>   static char B[100]={1};

This char arrays are modifyable because they're not const.

> Do these not also have static storage duration? Yet presumably these can 
> be legally modified.
> 

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

#387524

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[...]

> A string literal creates an array object with static storage
> duration.  [...]

A small quibble.  Every string literal does sit in an array,
but it might not be a _new_ array, because different string
literals are allowed to overlap as long as the bytes in the
overlapping arrays have the right values.

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

#387543

On 12/08/2024 22:11, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 
> [...]
> 
>> A string literal creates an array object with static storage
>> duration.  [...]
> 
> A small quibble.  Every string literal does sit in an array,
> but it might not be a _new_ array, because different string
> literals are allowed to overlap as long as the bytes in the
> overlapping arrays have the right values.

And this is exactly why string literals should always have been const.

A compiler is entitled to share memory between strings. so

	puts("lap");
	puts("overlap");

it's entitled to make them overlap. Then add

	char * p = "lap";
	*p='X';

and it can overwrite the shared string. I think. which would mean that 
writing "lap" again would have a different result.

But that ship has sailed. I'm not even sure const had been invented that 
far back!

Andy

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

#387547

Vir Campestris <vir.campestris@invalid.invalid> writes:
> On 12/08/2024 22:11, Tim Rentsch wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [...]
>> 
>>> A string literal creates an array object with static storage
>>> duration.  [...]
>> A small quibble.  Every string literal does sit in an array,
>> but it might not be a _new_ array, because different string
>> literals are allowed to overlap as long as the bytes in the
>> overlapping arrays have the right values.
>
> And this is exactly why string literals should always have been const.
>
> A compiler is entitled to share memory between strings. so
>
> 	puts("lap");
> 	puts("overlap");
>
> it's entitled to make them overlap. Then add
>
> 	char * p = "lap";
> 	*p='X';
>
> and it can overwrite the shared string. I think. which would mean that
> writing "lap" again would have a different result.
>
> But that ship has sailed. I'm not even sure const had been invented
> that far back!

The reason that *wasn't* done is that it would have broken existing
code.

In pre-ANSI C, "const" didn't exist, and this:
    char *ptr = "hello";
was the only way to create a pointer into a string literal object.
Making string literals const would have broken such code, with no clean
way to rewrite it so it would be accepted by old and new compilers.

I suppose you could do something like:

#ifndef __STDC__
#define const
#endif

In 20/20 hindsight, my personal opinion is that it would have been
better to make string literals const in C89/C90.  Compilers could
still accept old const-incorrect code with a non-fatal warning,
and programmers would be encouraged but not immediately forced to
use const.

This could still be done in C2y, but I'm not aware of any proposals.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#387555

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> In 20/20 hindsight, my personal opinion is that it would have been
> better to make string literals const in C89/C90.

Fortunately wiser heads prevailed.

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

#387563

On 13/08/2024 22:08, Keith Thompson wrote:

> In 20/20 hindsight, my personal opinion is that it would have been
> better to make string literals const in C89/C90.  Compilers could
> still accept old const-incorrect code with a non-fatal warning,
> and programmers would be encouraged but not immediately forced to
> use const.
> 

Agreed.

That's basically what happened when C++ was designed.

> This could still be done in C2y, but I'm not aware of any proposals.
> 

There is always going to be some hassle with things like search 
functions - 100% const correctness is not easy when you don't have 
overloads.  (It's not always easy even in C++ where you /do/ have 
overloads and templates.)

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

#387554

Vir Campestris <vir.campestris@invalid.invalid> writes:

> On 12/08/2024 22:11, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [...]
>>
>>> A string literal creates an array object with static storage
>>> duration.  [...]
>>
>> A small quibble.  Every string literal does sit in an array,
>> but it might not be a _new_ array, because different string
>> literals are allowed to overlap as long as the bytes in the
>> overlapping arrays have the right values.
>
> And this is exactly why string literals should always have been
> const.

The people who wrote the C standard reached a different
conclusion, and IMO the right one.

> A compiler is entitled to share memory between strings.  so
>
>     puts("lap");
>     puts("overlap");
>
> it's entitled to make them overlap.  Then add
>
>     char * p = "lap";
>     *p='X';
>
> and it can overwrite the shared string.  I think.  which would
> mean that writing "lap" again would have a different result.

A C implementation is also allowed to put every string literal
in its own separate array object, not shared even when two
or more string literals are identical, and make them writable
so they can be modified without problems.  I believe some C
compilers actually did this, perhaps under the control of a
compilation option.

> But that ship has sailed.  I'm not even sure const had been
> invented that far back!

C was already well established before 'const' was invented, and it
was a number of years after that before some C compilers started
allowing 'const' in source code.  The cost of not being backward
compatible would be high;  the cost adding const incrementally in
new code is low.  Generally speaking using string literals in open
code is a bad idea anyway, regardless whether there is any concern
that the string might be modified.  I think most people who want
string literals to be of type const char[] are only thinking about
one side of the equation.  It's always important to remember to
look at both sides of the cost/benefit forces, and not focus on
just the (imagined) benefits or (imagined) downsides.

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

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

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

csiph-web