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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#387338 — Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault?

On 8/4/2024 6:06 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> 
>> On 8/2/2024 3:29 PM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>> For some reason I had a sort of a habit wrt const pointers:
>>>>
>>>> (experimental code, no ads, raw text...)
>>>> https://pastebin.com/raw/f52a443b1
>>>>
>>>> ________________________________
>>>> /* Interfaces
>>>> ____________________________________________________________________*/
>>>> #include <stddef.h>
>>>>
>>>>
>>>> struct object_prv_vtable {
>>>>     int (*fp_destroy) (void* const);
>>>> };
>>>>
>>>>
>>>> struct device_prv_vtable {
>>>>     int (*fp_read) (void* const, void*, size_t);
>>>>     int (*fp_write) (void* const, void const*, size_t);
>>>> };
>>> Why?  It seems like an arbitrary choice to const qualify some pointer
>>> types and some pointed-to types (but never both).
>>
>> I just wanted to get the point across that the first parameter, aka, akin
>> to "this" in C++ is a const pointer. Shall not be modified in any way shape
>> or form. It is as it is, so to speak:
>>
>> void foo(struct foobar const* const self);
>>
>> constant pointer to a constant foobar, fair enough?
> 
> No.  If you intended a const pointer to const object why didn't you
> write that?  My point was that the consts seems to be scattered about
> without any apparent logic and you've not explained why.
> 
>>>> ;^)
>>> Does the wink mean I should not take what you write seriously?  If so,
>>> please ignore my question.
>>
>> The wink was meant to show my habit in basically a jestful sort of
>> way.
> 
> Your habit of what?
> 

To write the declaration with names and the const access I want, so:

extern void (void const* const ptr);

void (void const* const ptr)
{
    // ptr is a const pointer to a const void
}

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

#387339 — Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault?

On 8/4/2024 7:37 PM, Chris M. Thomasson wrote:
> On 8/4/2024 6:06 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>> On 8/2/2024 3:29 PM, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>
>>>>> For some reason I had a sort of a habit wrt const pointers:
>>>>>
>>>>> (experimental code, no ads, raw text...)
>>>>> https://pastebin.com/raw/f52a443b1
>>>>>
>>>>> ________________________________
>>>>> /* Interfaces
>>>>> ____________________________________________________________________*/
>>>>> #include <stddef.h>
>>>>>
>>>>>
>>>>> struct object_prv_vtable {
>>>>>     int (*fp_destroy) (void* const);
>>>>> };
>>>>>
>>>>>
>>>>> struct device_prv_vtable {
>>>>>     int (*fp_read) (void* const, void*, size_t);
>>>>>     int (*fp_write) (void* const, void const*, size_t);
>>>>> };
>>>> Why?  It seems like an arbitrary choice to const qualify some pointer
>>>> types and some pointed-to types (but never both).
>>>
>>> I just wanted to get the point across that the first parameter, aka, 
>>> akin
>>> to "this" in C++ is a const pointer. Shall not be modified in any way 
>>> shape
>>> or form. It is as it is, so to speak:
>>>
>>> void foo(struct foobar const* const self);
>>>
>>> constant pointer to a constant foobar, fair enough?
>>
>> No.  If you intended a const pointer to const object why didn't you
>> write that?  My point was that the consts seems to be scattered about
>> without any apparent logic and you've not explained why.
>>
>>>>> ;^)
>>>> Does the wink mean I should not take what you write seriously?  If so,
>>>> please ignore my question.
>>>
>>> The wink was meant to show my habit in basically a jestful sort of
>>> way.
>>
>> Your habit of what?
>>
> 
> To write the declaration with names and the const access I want, so:
> 
> extern void (void const* const ptr);
> 
> void (void const* const ptr)
> {
>     // ptr is a const pointer to a const void
> }
> 
> 
> 

Perhaps give the function a name... ;^)

To write the declaration with names and the const access I want, so:

extern void foobar(void const* const ptr);

void foobar(void const* const ptr)
{
    // ptr is a const pointer to a const void
}

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

#387350 — 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> writes:

> On 8/4/2024 6:06 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> 
>>> On 8/2/2024 3:29 PM, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>
>>>>> For some reason I had a sort of a habit wrt const pointers:
>>>>>
>>>>> (experimental code, no ads, raw text...)
>>>>> https://pastebin.com/raw/f52a443b1
>>>>>
>>>>> ________________________________
>>>>> /* Interfaces
>>>>> ____________________________________________________________________*/
>>>>> #include <stddef.h>
>>>>>
>>>>>
>>>>> struct object_prv_vtable {
>>>>>     int (*fp_destroy) (void* const);
>>>>> };
>>>>>
>>>>>
>>>>> struct device_prv_vtable {
>>>>>     int (*fp_read) (void* const, void*, size_t);
>>>>>     int (*fp_write) (void* const, void const*, size_t);
>>>>> };
>>>> Why?  It seems like an arbitrary choice to const qualify some pointer
>>>> types and some pointed-to types (but never both).
>>>
>>> I just wanted to get the point across that the first parameter, aka, akin
>>> to "this" in C++ is a const pointer. Shall not be modified in any way shape
>>> or form. It is as it is, so to speak:
>>>
>>> void foo(struct foobar const* const self);
>>>
>>> constant pointer to a constant foobar, fair enough?
>> No.  If you intended a const pointer to const object why didn't you
>> write that?  My point was that the consts seems to be scattered about
>> without any apparent logic and you've not explained why.
>> 
>>>>> ;^)
>>>> Does the wink mean I should not take what you write seriously?  If so,
>>>> please ignore my question.
>>>
>>> The wink was meant to show my habit in basically a jestful sort of
>>> way.
>> Your habit of what?
>
> To write the declaration with names and the const access I want, so:
>
> extern void (void const* const ptr);
>
> void (void const* const ptr)
> {
>    // ptr is a const pointer to a const void
> }

I don't think you are following what I'm, saying.  If you think there
might be some value in finding out, you could as a few questions.  I
won't say it again ;-)

-- 
Ben.

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

#387360 — Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault?

On 8/5/2024 4:03 AM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> 
>> On 8/4/2024 6:06 PM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>> On 8/2/2024 3:29 PM, Ben Bacarisse wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>
>>>>>> For some reason I had a sort of a habit wrt const pointers:
>>>>>>
>>>>>> (experimental code, no ads, raw text...)
>>>>>> https://pastebin.com/raw/f52a443b1
>>>>>>
>>>>>> ________________________________
>>>>>> /* Interfaces
>>>>>> ____________________________________________________________________*/
>>>>>> #include <stddef.h>
>>>>>>
>>>>>>
>>>>>> struct object_prv_vtable {
>>>>>>      int (*fp_destroy) (void* const);
>>>>>> };
>>>>>>
>>>>>>
>>>>>> struct device_prv_vtable {
>>>>>>      int (*fp_read) (void* const, void*, size_t);
>>>>>>      int (*fp_write) (void* const, void const*, size_t);
>>>>>> };
>>>>> Why?  It seems like an arbitrary choice to const qualify some pointer
>>>>> types and some pointed-to types (but never both).
>>>>
>>>> I just wanted to get the point across that the first parameter, aka, akin
>>>> to "this" in C++ is a const pointer. Shall not be modified in any way shape
>>>> or form. It is as it is, so to speak:
>>>>
>>>> void foo(struct foobar const* const self);
>>>>
>>>> constant pointer to a constant foobar, fair enough?
>>> No.  If you intended a const pointer to const object why didn't you
>>> write that?  My point was that the consts seems to be scattered about
>>> without any apparent logic and you've not explained why.
>>>
>>>>>> ;^)
>>>>> Does the wink mean I should not take what you write seriously?  If so,
>>>>> please ignore my question.
>>>>
>>>> The wink was meant to show my habit in basically a jestful sort of
>>>> way.
>>> Your habit of what?
>>
>> To write the declaration with names and the const access I want, so:
>>
>> extern void (void const* const ptr);
>>
>> void (void const* const ptr)
>> {
>>     // ptr is a const pointer to a const void
>> }
> 
> I don't think you are following what I'm, saying.  If you think there
> might be some value in finding out, you could as a few questions.  I
> won't say it again ;-)
> 

I must be misunderstanding you. My habit in such code was to always make 
the "this" pointer wrt some of my "object" oriented code a const 
pointer. This was always the first parameter:

extern void foobar(void const* const ptr);

or

extern void foobar(void* const ptr);


Actually, I used the name of self for a while.


extern void foobar(void const* const self);
extern void foobar(void* const self);

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

#387361 — 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> writes:

> On 8/5/2024 4:03 AM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> 
>>> On 8/4/2024 6:06 PM, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>
>>>>> On 8/2/2024 3:29 PM, Ben Bacarisse wrote:
>>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>>
>>>>>>> For some reason I had a sort of a habit wrt const pointers:
>>>>>>>
>>>>>>> (experimental code, no ads, raw text...)
>>>>>>> https://pastebin.com/raw/f52a443b1
>>>>>>>
>>>>>>> ________________________________
>>>>>>> /* Interfaces
>>>>>>> ____________________________________________________________________*/
>>>>>>> #include <stddef.h>
>>>>>>>
>>>>>>>
>>>>>>> struct object_prv_vtable {
>>>>>>>      int (*fp_destroy) (void* const);
>>>>>>> };
>>>>>>>
>>>>>>>
>>>>>>> struct device_prv_vtable {
>>>>>>>      int (*fp_read) (void* const, void*, size_t);
>>>>>>>      int (*fp_write) (void* const, void const*, size_t);
>>>>>>> };
>>>>>> Why?  It seems like an arbitrary choice to const qualify some pointer
>>>>>> types and some pointed-to types (but never both).
>>>>>
>>>>> I just wanted to get the point across that the first parameter, aka, akin
>>>>> to "this" in C++ is a const pointer. Shall not be modified in any way shape
>>>>> or form. It is as it is, so to speak:
>>>>>
>>>>> void foo(struct foobar const* const self);
>>>>>
>>>>> constant pointer to a constant foobar, fair enough?
>>>> No.  If you intended a const pointer to const object why didn't you
>>>> write that?  My point was that the consts seems to be scattered about
>>>> without any apparent logic and you've not explained why.
>>>>
>>>>>>> ;^)
>>>>>> Does the wink mean I should not take what you write seriously?  If so,
>>>>>> please ignore my question.
>>>>>
>>>>> The wink was meant to show my habit in basically a jestful sort of
>>>>> way.
>>>> Your habit of what?
>>>
>>> To write the declaration with names and the const access I want, so:
>>>
>>> extern void (void const* const ptr);
>>>
>>> void (void const* const ptr)
>>> {
>>>     // ptr is a const pointer to a const void
>>> }
>> I don't think you are following what I'm, saying.  If you think there
>> might be some value in finding out, you could as a few questions.  I
>> won't say it again ;-)
>
> I must be misunderstanding you. My habit in such code was to always make
> the "this" pointer wrt some of my "object" oriented code a const
> pointer. This was always the first parameter:
>
> extern void foobar(void const* const ptr);

OK.  So I conclude you don't want to know what I was saying.  That's
fine.  It was a trivial point.

-- 
Ben.

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

#387364 — Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault?

On 8/5/2024 1:54 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> 
>> On 8/5/2024 4:03 AM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>> On 8/4/2024 6:06 PM, Ben Bacarisse wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>
>>>>>> On 8/2/2024 3:29 PM, Ben Bacarisse wrote:
>>>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>>>
>>>>>>>> For some reason I had a sort of a habit wrt const pointers:
>>>>>>>>
>>>>>>>> (experimental code, no ads, raw text...)
>>>>>>>> https://pastebin.com/raw/f52a443b1
>>>>>>>>
>>>>>>>> ________________________________
>>>>>>>> /* Interfaces
>>>>>>>> ____________________________________________________________________*/
>>>>>>>> #include <stddef.h>
>>>>>>>>
>>>>>>>>
>>>>>>>> struct object_prv_vtable {
>>>>>>>>       int (*fp_destroy) (void* const);
>>>>>>>> };
>>>>>>>>
>>>>>>>>
>>>>>>>> struct device_prv_vtable {
>>>>>>>>       int (*fp_read) (void* const, void*, size_t);
>>>>>>>>       int (*fp_write) (void* const, void const*, size_t);
>>>>>>>> };
>>>>>>> Why?  It seems like an arbitrary choice to const qualify some pointer
>>>>>>> types and some pointed-to types (but never both).
>>>>>>
>>>>>> I just wanted to get the point across that the first parameter, aka, akin
>>>>>> to "this" in C++ is a const pointer. Shall not be modified in any way shape
>>>>>> or form. It is as it is, so to speak:
>>>>>>
>>>>>> void foo(struct foobar const* const self);
>>>>>>
>>>>>> constant pointer to a constant foobar, fair enough?
>>>>> No.  If you intended a const pointer to const object why didn't you
>>>>> write that?  My point was that the consts seems to be scattered about
>>>>> without any apparent logic and you've not explained why.
>>>>>
>>>>>>>> ;^)
>>>>>>> Does the wink mean I should not take what you write seriously?  If so,
>>>>>>> please ignore my question.
>>>>>>
>>>>>> The wink was meant to show my habit in basically a jestful sort of
>>>>>> way.
>>>>> Your habit of what?
>>>>
>>>> To write the declaration with names and the const access I want, so:
>>>>
>>>> extern void (void const* const ptr);
>>>>
>>>> void (void const* const ptr)
>>>> {
>>>>      // ptr is a const pointer to a const void
>>>> }
>>> I don't think you are following what I'm, saying.  If you think there
>>> might be some value in finding out, you could as a few questions.  I
>>> won't say it again ;-)
>>
>> I must be misunderstanding you. My habit in such code was to always make
>> the "this" pointer wrt some of my "object" oriented code a const
>> pointer. This was always the first parameter:
>>
>> extern void foobar(void const* const ptr);
> 
> OK.  So I conclude you don't want to know what I was saying.  That's
> fine.  It was a trivial point.
> 

I must have completely missed it. Sorry about that. Please redefine?

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

#387373 — 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> writes:

> I must have completely missed it. Sorry about that. Please redefine?

It's going to seem silly after all these exchanges.  I simply wanted to
know why you chose to use const as you originally posted:

| struct object_prv_vtable {
|       int (*fp_destroy) (void* const);
|       int (*fp_read) (void* const, void*, size_t);
|       int (*fp_write) (void* const, void const*, size_t);
| };

because that looks peculiar (to the point of being arbitrary) to me.
You went on to talk about "self" pointers being const pointers to const
void, but that was not what you wrote, so it did not address what I was
asking about.

In general, const qualified argument types are rarely used and are even
more rarely used in function (or type) declarations because there have
no effect at all in that position.  For example, I can assign fp_destroy
from a function declared without the const-qualified parameter:

   int destroy(void *self) { /* ... */; return 1; }
   ...
   vtab.fp_destroy = destroy;

or, if I do want the compiler to check that the function does not alter
its parameter, I can add the const in the function definition (were it
can be useful) even if it is missing from the declaration:

  struct object_prv_vtable {
        int (*fp_destroy) (void*);
        /* ... */
  };

  int destroy(void *const self) { /* ... */; return 1; }
  ...
  vtab.fp_destroy = destroy;

But if you want the const there so that the declaration matches the
function defintion, why not do that for all the parameters?  Basically,
I would have expercted either this (just ine const where it matters):

struct object_prv_vtable {
      int (*fp_destroy) (void *);
      int (*fp_read) (void *, void *, size_t);
      int (*fp_write) (void *, void const *, size_t);
};

and the actual functions that get assigned to these pointers might, if
you want that extra check, have all their parametera marked const.  Or,
for consistency, you might have written

struct object_prv_vtable {
      int (*fp_destroy) (void * const);
      int (*fp_read) (void * const, void * const, size_t const);
      int (*fp_write) (void * const, void const * const, size_t const);
};

even if none of the actual functions have const parameters.

Finally, if you had intended to write what you later went on to talk
about, you would have written either

struct object_prv_vtable {
      int (*fp_destroy) (const void *);
      int (*fp_read) (const void *, void *, size_t);
      int (*fp_write) (const void *, void const *, size_t);
};

or

struct object_prv_vtable {
      int (*fp_destroy) (const void * const);
      int (*fp_read) (const void * const, void * const, size_t const);
      int (*fp_write) (const void * const, void const * const, size_t const);
};

TL;DR: where you put the consts in the original just seemed arbitrary.


I'll also note that the term "const pointer" is often used when the
pointer is not const!  It most often mean that the pointed-to type is
const qualified.  As such, it's best to avoid the term altogether.

-- 
Ben.

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

#387376 — Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault?

On 8/6/2024 4:29 AM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> 
>> I must have completely missed it. Sorry about that. Please redefine?
> 
> It's going to seem silly after all these exchanges.  I simply wanted to
> know why you chose to use const as you originally posted:
> 
> | struct object_prv_vtable {
> |       int (*fp_destroy) (void* const);
> |       int (*fp_read) (void* const, void*, size_t);
> |       int (*fp_write) (void* const, void const*, size_t);
> | };
> 
> because that looks peculiar (to the point of being arbitrary) to me.
> You went on to talk about "self" pointers being const pointers to const
> void, but that was not what you wrote, so it did not address what I was
> asking about.
> 
> In general, const qualified argument types are rarely used and are even
> more rarely used in function (or type) declarations because there have
> no effect at all in that position.  For example, I can assign fp_destroy
> from a function declared without the const-qualified parameter:
> 
>     int destroy(void *self) { /* ... */; return 1; }
>     ...
>     vtab.fp_destroy = destroy;
> 
> or, if I do want the compiler to check that the function does not alter
> its parameter, I can add the const in the function definition (were it
> can be useful) even if it is missing from the declaration:
> 
>    struct object_prv_vtable {
>          int (*fp_destroy) (void*);
>          /* ... */
>    };
> 
>    int destroy(void *const self) { /* ... */; return 1; }
>    ...
>    vtab.fp_destroy = destroy;
> 
> But if you want the const there so that the declaration matches the
> function defintion, why not do that for all the parameters?  Basically,
> I would have expercted either this (just ine const where it matters):
> 
> struct object_prv_vtable {
>        int (*fp_destroy) (void *);
>        int (*fp_read) (void *, void *, size_t);
>        int (*fp_write) (void *, void const *, size_t);
> };
> 
> and the actual functions that get assigned to these pointers might, if
> you want that extra check, have all their parametera marked const.  Or,
> for consistency, you might have written
> 
> struct object_prv_vtable {
>        int (*fp_destroy) (void * const);
>        int (*fp_read) (void * const, void * const, size_t const);
>        int (*fp_write) (void * const, void const * const, size_t const);
> };
> 
> even if none of the actual functions have const parameters.
> 
> Finally, if you had intended to write what you later went on to talk
> about, you would have written either
> 
> struct object_prv_vtable {
>        int (*fp_destroy) (const void *);
>        int (*fp_read) (const void *, void *, size_t);
>        int (*fp_write) (const void *, void const *, size_t);
> };
> 
> or
> 
> struct object_prv_vtable {
>        int (*fp_destroy) (const void * const);
>        int (*fp_read) (const void * const, void * const, size_t const);
>        int (*fp_write) (const void * const, void const * const, size_t const);
> };
> 
> TL;DR: where you put the consts in the original just seemed arbitrary.
> 
> 
> I'll also note that the term "const pointer" is often used when the
> pointer is not const!  It most often mean that the pointed-to type is
> const qualified.  As such, it's best to avoid the term altogether.
> 

I wanted to get across that the pointer value for the first parameter 
itself should not be modified. I read (void* const) as a const pointer 
to a "non-const" void. Now a const pointer to a const void is (void 
const* const), from my code, notice the first parameter?

I consider the first parameter to be special in this older OO experiment 
of mine. It shall not be modified, so I wrote it into the API:

struct device_prv_vtable {
   int (*fp_read) (void* const, void*, size_t);
   int (*fp_write) (void* const, void const*, size_t);
};

// impl...
static int usb_drive_device_read(void* const, void*, size_t);
static int usb_drive_device_write(void* const, void const*, size_t);


int usb_drive_device_read(
  void* const self_,
  void* buf,
  size_t size
) {
   struct usb_drive* const self = self_;
   printf("usb_drive_device_read(%p, %p, %lu)\n",
     (void*)self, buf, (unsigned long)size);
   return 0;
}


int usb_drive_device_write(
  void* const self_,
  void const* buf,
  size_t size
) {
   struct usb_drive* const self = self_;
   printf("usb_drive_device_write(%p, %p, %lu)\n",
     (void*)self, buf, (unsigned long)size);
   return 0;
}

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

#387378 — 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> writes:

> On 8/6/2024 4:29 AM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> 
>>> I must have completely missed it. Sorry about that. Please redefine?
>> It's going to seem silly after all these exchanges.  I simply wanted to
>> know why you chose to use const as you originally posted:
>> | struct object_prv_vtable {
>> |       int (*fp_destroy) (void* const);
>> |       int (*fp_read) (void* const, void*, size_t);
>> |       int (*fp_write) (void* const, void const*, size_t);
>> | };
>> because that looks peculiar (to the point of being arbitrary) to me.
>> You went on to talk about "self" pointers being const pointers to const
>> void, but that was not what you wrote, so it did not address what I was
>> asking about.
>> In general, const qualified argument types are rarely used and are even
>> more rarely used in function (or type) declarations because there have
>> no effect at all in that position.  For example, I can assign fp_destroy
>> from a function declared without the const-qualified parameter:
>>     int destroy(void *self) { /* ... */; return 1; }
>>     ...
>>     vtab.fp_destroy = destroy;
>> or, if I do want the compiler to check that the function does not alter
>> its parameter, I can add the const in the function definition (were it
>> can be useful) even if it is missing from the declaration:
>>    struct object_prv_vtable {
>>          int (*fp_destroy) (void*);
>>          /* ... */
>>    };
>>    int destroy(void *const self) { /* ... */; return 1; }
>>    ...
>>    vtab.fp_destroy = destroy;
>> But if you want the const there so that the declaration matches the
>> function defintion, why not do that for all the parameters?  Basically,
>> I would have expercted either this (just ine const where it matters):
>> struct object_prv_vtable {
>>        int (*fp_destroy) (void *);
>>        int (*fp_read) (void *, void *, size_t);
>>        int (*fp_write) (void *, void const *, size_t);
>> };
>> and the actual functions that get assigned to these pointers might, if
>> you want that extra check, have all their parametera marked const.  Or,
>> for consistency, you might have written
>> struct object_prv_vtable {
>>        int (*fp_destroy) (void * const);
>>        int (*fp_read) (void * const, void * const, size_t const);
>>        int (*fp_write) (void * const, void const * const, size_t const);
>> };
>> even if none of the actual functions have const parameters.
>> Finally, if you had intended to write what you later went on to talk
>> about, you would have written either
>> struct object_prv_vtable {
>>        int (*fp_destroy) (const void *);
>>        int (*fp_read) (const void *, void *, size_t);
>>        int (*fp_write) (const void *, void const *, size_t);
>> };
>> or
>> struct object_prv_vtable {
>>        int (*fp_destroy) (const void * const);
>>        int (*fp_read) (const void * const, void * const, size_t const);
>>        int (*fp_write) (const void * const, void const * const, size_t const);
>> };
>> TL;DR: where you put the consts in the original just seemed arbitrary.
>> I'll also note that the term "const pointer" is often used when the
>> pointer is not const!  It most often mean that the pointed-to type is
>> const qualified.  As such, it's best to avoid the term altogether.
>
> I wanted to get across that the pointer value for the first parameter
> itself should not be modified. I read (void* const) as a const pointer to a
> "non-const" void. Now a const pointer to a const void is (void const*
> const), from my code, notice the first parameter?
>
> I consider the first parameter to be special in this older OO experiment of
> mine. It shall not be modified, so I wrote it into the API:

You could have said that when I asked many posts ago!  I can't see a
sound technical reason to put a const there but that parameter is in
some way different I suppose.  The effect on readers is likely to be a
puzzled, mild confusion.

Note that is not really "in the API" as it is entirely optional whether
the implementation has a const first parameter.

-- 
Ben.

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

#387532 — Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault?

On 8/6/2024 3:59 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
[...]

Also, take notice of:

struct device_vtable {
   struct object_prv_vtable const object;
   struct device_prv_vtable const device;
};

:^)

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

#387367 — Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault?

On 8/5/2024 1:54 PM, Ben Bacarisse wrote:
[...]

Another habit of mine was to write:

void* const self_,

or:

void* const this_,

For the first parameter... That trailing underscore... ;^o

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

#387526 — 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> writes:

> Richard Harnden <richard.nospam@gmail.invalid> writes:
> [...]
>
>> Is there any reason not to always write ...
>>
>> static const char *s = "hello, world";
>>
>> ... ?
>>
>> You get all the warnings for free that way.
>
> The "static", if this is at block scope, specifies that the
> pointer object, not the array object, has static storage duration.
> If it's at file scope it specifies that the name "s" is not
> visible to other translation units.  Either way, use it if that's
> what you want, don't use it if it isn't.
>
> There's no good reason not to use "const". [...]

Other people have different opinions on that question.

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

#387528 — 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> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>> [...]
>>
>>> Is there any reason not to always write ...
>>>
>>> static const char *s = "hello, world";
>>>
>>> ... ?
>>>
>>> You get all the warnings for free that way.
>>
>> The "static", if this is at block scope, specifies that the
>> pointer object, not the array object, has static storage duration.
>> If it's at file scope it specifies that the name "s" is not
>> visible to other translation units.  Either way, use it if that's
>> what you want, don't use it if it isn't.
>>
>> There's no good reason not to use "const". [...]
>
> Other people have different opinions on that question.

You could have told us your opinion.  You could have explained why
someone might have a different opinion.  You could have given us
a good reason not to use "const", assuming there is such a reason.
You know the language well enough to make me suspect you might have
something specific in mind.

That could have been interesting and useful.

Instead, you chose to waste everyone's time with a practically
content-free response.

Yes, different people have different opinions.  Golly, I never
knew that.

-- 
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]

#388108 — 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> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>>> [...]
>>>
>>>> Is there any reason not to always write ...
>>>>
>>>> static const char *s = "hello, world";
>>>>
>>>> ... ?
>>>>
>>>> You get all the warnings for free that way.
>>>
>>> The "static", if this is at block scope, specifies that the
>>> pointer object, not the array object, has static storage duration.
>>> If it's at file scope it specifies that the name "s" is not
>>> visible to other translation units.  Either way, use it if that's
>>> what you want, don't use it if it isn't.
>>>
>>> There's no good reason not to use "const".  [...]
>>
>> Other people have different opinions on that question.
>
> You could have told us your opinion.  You could have explained why
> someone might have a different opinion.  You could have given us a
> good reason not to use "const", assuming there is such a reason.
> You know the language well enough to make me suspect you might
> have something specific in mind.  [...]

I said all that I thought needed saying.  I see no reason
to add to it.

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

#387772 — Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault?

On Fri, 2 Aug 2024 13:04:55 +0100, Richard Harnden
<richard.nospam@gmail.invalid> wrote:

[string literals not typed const in C even though writing prohibited]

> Is there any reason not to always write ...
> 
> static const char *s = "hello, world";
> 
> ... ?
> 
> You get all the warnings for free that way.

But sizeof s is 8 or 4 regardless of the string, while sizeof "some
string" is the length of the string plus 1 (for the null terminator).

static const char s[] = "hello, world"; 
// autosized by initializer

would be a better replacement, or in C99+ if at file scope

(const char[]){"hello, world"}

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

#387779 — 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 writes:
> On Fri, 2 Aug 2024 13:04:55 +0100, Richard Harnden
> <richard.nospam@gmail.invalid> wrote:
>
> [string literals not typed const in C even though writing prohibited]
>
>> Is there any reason not to always write ...
>> 
>> static const char *s = "hello, world";
>> 
>> ... ?
>> 
>> You get all the warnings for free that way.
>
> But sizeof s is 8 or 4 regardless of the string, while sizeof "some
> string" is the length of the string plus 1 (for the null terminator).
>
> static const char s[] = "hello, world"; 
> // autosized by initializer
>
> would be a better replacement, or in C99+ if at file scope
>
> (const char[]){"hello, world"}

Most uses of that string are very likely to be via function arguments.

If it's defined at file scope, defining s as an array rather than as a
pointer can be useful for any code that refers to it directly (and needs
its size), but as soon as you pass it to a function you lose the size
information (and probably need to pass an extra argument for the
length).

-- 
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]

#387525 — 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> writes:

> candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
> writes:
>
>> David Brown <david.brown@hesbynett.no> wrote at 17:56 this Thursday (GMT):
>
> [...]
>
>>> gcc has the option "-Wwrite-strings" that makes string literals in
>>> C have "const char" array type, and thus give errors when you try
>>> to assign to a non-const char * pointer.  But the option has to be
>>> specified explicitly (it is not in -Wall) because it changes the
>>> meaning of the code and can cause compatibility issues with
>>> existing correct code.
>>
>> -Wwrite-strings is included in -Wpedantic.
>
> No it isn't, nor is it included in -Wall -- and it wouldn't make
> sense to do so.
>
> The -Wpedantic option is intended to produce all required
> diagnostics for the specified C standard.  -Wwrite-strings
> gives string literals the type `const char[LENGTH]`, which
> enables useful diagnostics but is *non-conforming*.

As long as the -Wwrite-strings diagnostics are only warnings the
result is still conforming.

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

#387527 — 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> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
>> writes:
>>> David Brown <david.brown@hesbynett.no> wrote at 17:56 this Thursday (GMT):
>> [...]
>>
>>>> gcc has the option "-Wwrite-strings" that makes string literals in
>>>> C have "const char" array type, and thus give errors when you try
>>>> to assign to a non-const char * pointer.  But the option has to be
>>>> specified explicitly (it is not in -Wall) because it changes the
>>>> meaning of the code and can cause compatibility issues with
>>>> existing correct code.
>>>
>>> -Wwrite-strings is included in -Wpedantic.
>>
>> No it isn't, nor is it included in -Wall -- and it wouldn't make
>> sense to do so.
>>
>> The -Wpedantic option is intended to produce all required
>> diagnostics for the specified C standard.  -Wwrite-strings
>> gives string literals the type `const char[LENGTH]`, which
>> enables useful diagnostics but is *non-conforming*.
>
> As long as the -Wwrite-strings diagnostics are only warnings the
> result is still conforming.

It's not just about diagnostics.  This program:

#include <stdio.h>
int main(void) {
    puts(_Generic("hello",
                  char*: "char*",
                  const char*: "const char*",
                  default: "?"));
}

must print "char*" in a conforming implementation.  With
(gcc|clang) -Wwrite-strings, it prints "const char*".

And something as simple as:

    char *p = "hello";

is rejected with a fatal error with "-Wwrite-strings -pedantic-errors".

-- 
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]

#387531 — 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> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
>>> writes:
>>>
>>>> David Brown <david.brown@hesbynett.no> wrote at 17:56 this Thursday (GMT):
>>>
>>> [...]
>>>
>>>>> gcc has the option "-Wwrite-strings" that makes string literals in
>>>>> C have "const char" array type, and thus give errors when you try
>>>>> to assign to a non-const char * pointer.  But the option has to be
>>>>> specified explicitly (it is not in -Wall) because it changes the
>>>>> meaning of the code and can cause compatibility issues with
>>>>> existing correct code.
>>>>
>>>> -Wwrite-strings is included in -Wpedantic.
>>>
>>> No it isn't, nor is it included in -Wall -- and it wouldn't make
>>> sense to do so.
>>>
>>> The -Wpedantic option is intended to produce all required
>>> diagnostics for the specified C standard.  -Wwrite-strings
>>> gives string literals the type `const char[LENGTH]`, which
>>> enables useful diagnostics but is *non-conforming*.
>>
>> As long as the -Wwrite-strings diagnostics are only warnings the
>> result is still conforming.
>
> It's not just about diagnostics.  This program:
>
> #include <stdio.h>
> int main(void) {
>     puts(_Generic("hello",
>                   char*:  "char*",
>                   const char*:  "const char*",
>                   default: "?"));
> }
>
> must print "char*" in a conforming implementation.  With
> (gcc|clang) -Wwrite-strings, it prints "const char*".

Good point.  I hadn't considered such cases.

> And something as simple as:
>
>     char *p = "hello";
>
> is rejected with a fatal error with "-Wwrite-strings -pedantic-errors".

That violates the "As long as the -Wwrite-strings diagnostics are
only warnings" condition.

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

#387540 — Re: No warning at implicit removal of const. Was: relearning C: why does an in-place change to a char* segfault?

On 13/08/2024 01:05, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
>>>> writes:
>>>>
>>>>> David Brown <david.brown@hesbynett.no> wrote at 17:56 this Thursday (GMT):
>>>>
>>>> [...]
>>>>
>>>>>> gcc has the option "-Wwrite-strings" that makes string literals in
>>>>>> C have "const char" array type, and thus give errors when you try
>>>>>> to assign to a non-const char * pointer.  But the option has to be
>>>>>> specified explicitly (it is not in -Wall) because it changes the
>>>>>> meaning of the code and can cause compatibility issues with
>>>>>> existing correct code.
>>>>>
>>>>> -Wwrite-strings is included in -Wpedantic.
>>>>
>>>> No it isn't, nor is it included in -Wall -- and it wouldn't make
>>>> sense to do so.
>>>>
>>>> The -Wpedantic option is intended to produce all required
>>>> diagnostics for the specified C standard.  -Wwrite-strings
>>>> gives string literals the type `const char[LENGTH]`, which
>>>> enables useful diagnostics but is *non-conforming*.
>>>
>>> As long as the -Wwrite-strings diagnostics are only warnings the
>>> result is still conforming.
>>
>> It's not just about diagnostics.  This program:
>>
>> #include <stdio.h>
>> int main(void) {
>>      puts(_Generic("hello",
>>                    char*:  "char*",
>>                    const char*:  "const char*",
>>                    default: "?"));
>> }
>>
>> must print "char*" in a conforming implementation.  With
>> (gcc|clang) -Wwrite-strings, it prints "const char*".
> 
> Good point.  I hadn't considered such cases.
> 
>> And something as simple as:
>>
>>      char *p = "hello";
>>
>> is rejected with a fatal error with "-Wwrite-strings -pedantic-errors".
> 
> That violates the "As long as the -Wwrite-strings diagnostics are
> only warnings" condition.

Indeed.

I personally think it is nice to have an option to make string literals 
"const" in C, even though it is non-conforming.  I also think it is very 
useful to have a warning on attempts to write to string literals.  But I 
think gcc has made a mistake here by conflating the two.  I'd rather see 
the warning being enabled by default (or at least in -Wall), while the 
"make string literals const" option should require an explicit flag and 
be a "-f" flag rather than a "-W" flag.  The current situation seems to 
be a quick-and-dirty way to get the warning.

Other people may have different opinions, of course :-)

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

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

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

csiph-web