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

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

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);
}

I know there are better ways to do ASCII uppercase, I don't care about 
that; what I don't understand is why I can't do an in-place edit of a non-
const char*?

I build using scons, which does: 

gcc -o inplace.o -c -Wall -g inplace.c

gcc -o inplace inplace.o

The error with gdb is:

Starting program: /tmp/inplace/inplace 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
before [this is a test]

Program received signal SIGSEGV, Segmentation fault.
0x000055555555516e in uppercase_ascii (s=0x555555556004 "this is a test") 
at inplace.c:6
6	        *s = toupper(*s);

[toc] | [next] | [standalone]

#387230

The formatting was messed up by Pan.

The function was:

void uppercase_ascii(char *s) {
    while (*s) {
        *s = toupper(*s); 
        s++;
    }
}

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

#387234

Mark Summerfield <mark@qtrac.eu> writes:

> The formatting was messed up by Pan.
>
> The function was:
>
> void uppercase_ascii(char *s) {
>     while (*s) {
>         *s = toupper(*s);

There's a tricky technicality with all of the character functions.  They
take an int argument so that EOF (typically -1) can be passed, but
otherwise the argument must be an int "which shall be representable as
an unsigned char" or the result is undefined.

If char is signed (as it very often is) then in some locales, like the
ISO-8859-* ones, many lower-case letters are negative so, to be 100%
portable, you should write

    *s = toupper((unsigned char)*s);

Now, since the behaviour is undefined, many implementations "do what you
want" but that only means you won't spot the bug by testing until the
code is linked to some old library that does not fix the issue!

>         s++;
>     }
> }

Note that this does not crop up in a typical input loop:

  int ch;
  while ((ch = getchar()) != EOF)
     putchar(toupper(ch));

because the input function "obtains [the] character as an unsigned char
converted to an int".

-- 
Ben.

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

#387231

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.

Change it to:

char text[] = "this is a test";

You can modify that, text gets it's own copy.

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

#387232

On Thu, 1 Aug 2024 09:38:13 +0100, Richard Harnden wrote:

[snip]
> text is pointing to "this is a test" - and that is stored in the program
> binary and that's why can't modify it.
> 
> Change it to:
> 
> char text[] = "this is a test";
> 
> You can modify that, text gets it's own copy.

Thanks that works; & thanks for the explanation.

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

#387233

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

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

#387242

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.  (Which
means there's no guarantee that your program will crash.)

Storing the array in a memory segment that results in a trap on an
attempt to modify it is probably the most common implementation
strategy.  Storing the array in writable memory is another, but is rare
these days.  (gcc had an option to do this, but it was removed some time
ago).

If you want a pointer to a string literal, it's best to define it as
"const", so attempts to write to it can be caught at compile time:

    const char* text = "this is a test";

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

#387244

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};

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

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

#387246

Bart <bc@freeuk.com> writes:
> 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};
>
> Do these not also have static storage duration? Yet presumably these
> can be legally modified.

Perhaps you thought I meant to imply that objects with static storage
duration are read-only.  I didn't.  I wrote "A string literal creates an
array object with static storage duration.  Any attempt to modify that
array object has undefined behavior."  Both statements are true, and
neither follows from the other.

An array object associated with a string literal has static storage
duration because the standard says so.  Attempting to modify such an
object has undefined behavior because the standard says so.

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

#387248

Bart <bc@freeuk.com> writes:
> On 01/08/2024 21:59, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
...
>>> 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};

The difference is that when 6.4.5p7 says ""... If the program attempts
to modify such an array, the behavior is undefined.", it is not talking
about arrays with static storage duration in general, but only
specifically about the arrays with static storage duration that are
created to store the contents of string literals.

For other arrays, whether or not it is defined behavior to modify them
depends upon whether or not the array's definition is const-qualified.
The arrays associated with string literals should have been specified as
const-qualified, in which case any code that put them at risk of being
modified would have required either a cast or a diagnostic.

In C++ string literals are const-qualified, but "const" was a late
addition to C, and by the time it was added to C, the committee's desire
to ensure backwards compatibility prevented doing so in what would
otherwise have been the most reasonable way.

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

#387250

On 2024-08-01, Bart <bc@freeuk.com> wrote:
>>> 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:

Programming languages can have objects that have the same lifetime, yet some
of which are mutable and some of which are immutable.

If the compiler believes that the immutable objects are in fact
not mutated, it's a bad idea to modify them behind the compiler's
back.

There doesn't have to be any actual difference in the implementation of
these objects, like in what area they are stored, other than the rules
regarding their correct use, namely prohibiting modification.

The Racket language has both mutable and immutable cons cells.
The difference is that the immutable cons cells simply lack the
operations needed to mutate them. I'm not an expert on the Racket
internals but I don't see a reason why they couldn't be stored in the
same heap.

>   static char A[100];
>   static char B[100]={1};
>
> Do these not also have static storage duration? Yet presumably these can 
> be legally modified.

That 1 which initializes B[0] cannot be modified.

There is no portable way to request that.

C++ implementations have late initialization for block scope statics.

A program which somehow gains access to the initialization data for those,
and modifies it, would be squarely in undefined behavior territory.

In mainstream C implementations there typically isn't a separate storage
for the initialization data for statics. They are set up before the
program runs.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#387253

On 02/08/2024 02:06, Kaz Kylheku wrote:
> On 2024-08-01, Bart <bc@freeuk.com> wrote:
>>>> 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:
> 
> Programming languages can have objects that have the same lifetime, yet some
> of which are mutable and some of which are immutable.
> 
> If the compiler believes that the immutable objects are in fact
> not mutated, it's a bad idea to modify them behind the compiler's
> back.
> 
> There doesn't have to be any actual difference in the implementation of
> these objects, like in what area they are stored, other than the rules
> regarding their correct use, namely prohibiting modification.
> 
> The Racket language has both mutable and immutable cons cells.
> The difference is that the immutable cons cells simply lack the
> operations needed to mutate them. I'm not an expert on the Racket
> internals but I don't see a reason why they couldn't be stored in the
> same heap.
> 
>>    static char A[100];
>>    static char B[100]={1};
>>
>> Do these not also have static storage duration? Yet presumably these can
>> be legally modified.
> 
> That 1 which initializes B[0] cannot be modified.
> 

Why not? I haven't requested that those are 'const'. Further, gcc has no 
problem running this program:

     static char A[100];
     static char B[100]={1};

     printf("%d %d %d\n", A[0], B[0], 1);
     A[0]=55;
     B[0]=89;
     printf("%d %d %d\n", A[0], B[0], 1);

But it does use readonly memory for string literals.

(The point of A and B was to represent .bss and .data segments 
respectively. A's data is not part of the EXE image; B's is.

While the point of 'static' was to avoid having to specify whether A and 
B were at module scope or within a function.)

 > That 1 which initializes B[0] cannot be modified.

Or do you literally mean the value of that '1'? Then it doesn' make 
sense; here that is a copy of the literal stored in one cell of 'B'. The 
value of the cell can change, then that particular copy of '1' is lost.

Here:

     static char B[100] = {1, 1, 1, 1, 1, 1};

changing B[0] will not affect the 1s in B[1..5], and in my example 
above, that standalone '1' is not affected.

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

#387261

On 8/2/24 5:43 AM, Bart wrote:
> On 02/08/2024 02:06, Kaz Kylheku wrote:
>> On 2024-08-01, Bart <bc@freeuk.com> wrote:
>>>>> 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:
>>
>> Programming languages can have objects that have the same lifetime, 
>> yet some
>> of which are mutable and some of which are immutable.
>>
>> If the compiler believes that the immutable objects are in fact
>> not mutated, it's a bad idea to modify them behind the compiler's
>> back.
>>
>> There doesn't have to be any actual difference in the implementation of
>> these objects, like in what area they are stored, other than the rules
>> regarding their correct use, namely prohibiting modification.
>>
>> The Racket language has both mutable and immutable cons cells.
>> The difference is that the immutable cons cells simply lack the
>> operations needed to mutate them. I'm not an expert on the Racket
>> internals but I don't see a reason why they couldn't be stored in the
>> same heap.
>>
>>>    static char A[100];
>>>    static char B[100]={1};
>>>
>>> Do these not also have static storage duration? Yet presumably these can
>>> be legally modified.
>>
>> That 1 which initializes B[0] cannot be modified.
>>
> 
> Why not? I haven't requested that those are 'const'. Further, gcc has no 
> problem running this program:
> 
>      static char A[100];
>      static char B[100]={1};
> 
>      printf("%d %d %d\n", A[0], B[0], 1);
>      A[0]=55;
>      B[0]=89;
>      printf("%d %d %d\n", A[0], B[0], 1);
> 
> But it does use readonly memory for string literals.
> 
> (The point of A and B was to represent .bss and .data segments 
> respectively. A's data is not part of the EXE image; B's is.
> 
> While the point of 'static' was to avoid having to specify whether A and 
> B were at module scope or within a function.)
> 
>  > That 1 which initializes B[0] cannot be modified.
> 
> Or do you literally mean the value of that '1'? Then it doesn' make 
> sense; here that is a copy of the literal stored in one cell of 'B'. The 
> value of the cell can change, then that particular copy of '1' is lost.
> 
> Here:
> 
>      static char B[100] = {1, 1, 1, 1, 1, 1};
> 
> changing B[0] will not affect the 1s in B[1..5], and in my example 
> above, that standalone '1' is not affected.
> 
> 

The key point is that the {1} isn't the value loclated in B[0], but the 
source of that value when B was initialize, which if B is in the .data 
segement is the source of the data to initialize that .data segement, 
which might exist nowhere in the actual ram memory of the machine, but 
might exist just in the file that was loaded.

WHen accessing the value of a string literal, the compiler needs to do 
something so value is accessible, perhaps by creating a const object 
created like any other const object, and exposing that.

The confusing part is that while it creates a "const char[]" object, the 
type of that object when refered to in code is just "char[]", the 
difference imposed to avoid breaking most code that used strings when 
the standard just was coming out.

Most implementations have an option to at least give a warning if used 
in a way that the const is lost, and most programs today should be 
compiled using that option.

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

#387263

On 8/2/24 5:43 AM, Bart wrote:
> On 02/08/2024 02:06, Kaz Kylheku wrote:
>> On 2024-08-01, Bart <bc@freeuk.com> wrote:
>>>>> 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};
>>>
>>> Do these not also have static storage duration? Yet presumably these can
>>> be legally modified.
>>
>> That 1 which initializes B[0] cannot be modified.
>>
> 
> Why not? I haven't requested that those are 'const'. ...

You don't get a choice in the matter. The C language doesn't permit
numeric literals of any kind to be modified by your code. They can't be,
and don't need to be, declared 'const'. I've heard that in some other
languages, if you call foo(3), and foo() changes the value of it's
argument to 2, then subsequent calls to bar(3) will pass a value of 2 to
bar(). That sounds like such a ridiculous mis-feature that I hesitate to
identify which languages I had heard accused of having that feature, but
it is important to note that C is not one of them.

Just as 1 is an integer literal whose value cannot be modified, "Hello,
world!" is a string literal whose contents cannot be safely modified.
The key difference is that, in many context "Hello, world!" gets
automatically converted into a pointer to it's first element, a feature
that makes it a lot easier to work with string literals - but also opens
up the possibility of attempting to write though that pointer. Doing so
has undefined behavior, which can include the consequences of storing
the contents of string literals in read-only memory.

That pointer's value should logically have had the type "const char*",
which would have made most attempts to write though that pointer
constraint violations, but the language didn't have 'const' at the time
that decision was made. In C++ the value is const-qualified. In C, the
best you can do is to make sure that if you define a pointer, and
initialize that pointer by setting it to point it inside a string
literal, you should declare that pointer as "const char*".

> ... Further, gcc has no 
> problem running this program:
> 
>      static char A[100];
>      static char B[100]={1};
> 
>      printf("%d %d %d\n", A[0], B[0], 1);
>      A[0]=55;
>      B[0]=89;
>      printf("%d %d %d\n", A[0], B[0], 1);

Of course, why should it? Neither A nor B are string literals, they are
only initialized by copying from a string literal. Since their
definitions are not const-qualified, there's no problems with such code.

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

#387265

On 02/08/2024 19:19, James Kuyper wrote:
> On 8/2/24 5:43 AM, Bart wrote:
>> On 02/08/2024 02:06, Kaz Kylheku wrote:
>>> On 2024-08-01, Bart <bc@freeuk.com> wrote:
>>>>>> 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};
>>>>
>>>> Do these not also have static storage duration? Yet presumably these can
>>>> be legally modified.
>>>
>>> That 1 which initializes B[0] cannot be modified.
>>>
>>
>> Why not? I haven't requested that those are 'const'. ...
> 
> You don't get a choice in the matter. The C language doesn't permit
> numeric literals of any kind to be modified by your code.

My post wasn't about numerical literals. I assumed it was about that '1' 
value which is stored B's first cell.

However, just in case KK was talking about that unlikely possibly, I 
covered that as well.

ey can't be,
> and don't need to be, declared 'const'. I've heard that in some other
> languages, if you call foo(3), and foo() changes the value of it's
> argument to 2, then subsequent calls to bar(3) will pass a value of 2 to
> bar(). That sounds like such a ridiculous mis-feature that I hesitate to
> identify which languages I had heard accused of having that feature, but
> it is important to note that C is not one of them.
> 
> Just as 1 is an integer literal whose value cannot be modified,

It can't modified, in a value that would also affect other instances of 
'1' within that module or produce, because it is very unlikely to be shared.

I don't know of any implementations of this kind of language which do 
that. (The nearest might FORTRAN IV when '1' was passed by reference to 
a subroutine, and the subroutine then assigns to that parameter.)

Where it would be more plausible is here:

    const char* B[] = {"A", "A", "A"};

where if you can somehow change that first "A", then the other two could 
also change if the compiler decides to share those 3 identical strings.

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

#387283

On Fri, 2 Aug 2024 14:19:49 -0400, James Kuyper wrote:

> I've heard that in some other
> languages, if you call foo(3), and foo() changes the value of it's
> argument to 2, then subsequent calls to bar(3) will pass a value of 2 to
> bar(). That sounds like such a ridiculous mis-feature that I hesitate to
> identify which languages I had heard accused of having that feature ...

I heard that, too. I think it was on some early FORTRAN compilers, on 
early machine architectures, without stacks or reentrancy. And with the 
weird FORTRAN argument-passing conventions.

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

#387287

On 8/2/24 9:31 PM, Lawrence D'Oliveiro wrote:
> On Fri, 2 Aug 2024 14:19:49 -0400, James Kuyper wrote:
> 
>> I've heard that in some other
>> languages, if you call foo(3), and foo() changes the value of it's
>> argument to 2, then subsequent calls to bar(3) will pass a value of 2 to
>> bar(). That sounds like such a ridiculous mis-feature that I hesitate to
>> identify which languages I had heard accused of having that feature ...
> 
> I heard that, too. I think it was on some early FORTRAN compilers, on
> early machine architectures, without stacks or reentrancy. And with the
> weird FORTRAN argument-passing conventions.

I remember it too, and was based on the fact that all arguments were 
pass by reference (so they could be either in or out parameters), and 
constants were passed as pointers to the location of memory where that 
constant was stored, and perhaps used elsewhere too. Why waste precious 
memory to setup a temporary to hold be initialized and hold the value, 
when you could just pass the address of a location that you knew had the 
right value.

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

#387297

Richard Damon <richard@damon-family.org> writes:

> On 8/2/24 9:31 PM, Lawrence D'Oliveiro wrote:
>> On Fri, 2 Aug 2024 14:19:49 -0400, James Kuyper wrote:
>> 
>>> I've heard that in some other
>>> languages, if you call foo(3), and foo() changes the value of it's
>>> argument to 2, then subsequent calls to bar(3) will pass a value of 2 to
>>> bar(). That sounds like such a ridiculous mis-feature that I hesitate to
>>> identify which languages I had heard accused of having that feature ...
>> I heard that, too. I think it was on some early FORTRAN compilers,
>> on
>> early machine architectures, without stacks or reentrancy. And with the
>> weird FORTRAN argument-passing conventions.
>
> I remember it too, and was based on the fact that all arguments were
> pass by reference (so they could be either in or out parameters), and
> constants were passed as pointers to the location of memory where that
> constant was stored, and perhaps used elsewhere too. Why waste
> precious memory to setup a temporary to hold be initialized and hold
> the value, when you could just pass the address of a location that you
> knew had the right value.

I actually had a bug once in my FORTRAN code on a CDC6400 where I changed the
value of an argument in a function, and then passed in a constant.  That
"constant" had the new value for the rest of the program.  Finding that
one was a challenge, particularly since I was a very inexperienced
undergrad at the time.

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

#387316

On Fri, 2 Aug 2024 22:01:21 -0400, Richard Damon wrote:

> ... was based on the fact that all arguments were pass by reference ...

Slightly more subtle than that: simple variables (and I think array 
elements) were passed by reference; more complex expressions had their 
value stored in a temporary and the temporary was passed by reference.

The “more complex” criterion could be triggered by something as simple as 
putting an extra pair of parentheses around a variable reference.

It was a calling convention that really made no logical sense.

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

#387506

Richard Damon <richard@damon-family.org> writes:

> On 8/2/24 9:31 PM, Lawrence D'Oliveiro wrote:
>
>> On Fri, 2 Aug 2024 14:19:49 -0400, James Kuyper wrote:
>>
>>> I've heard that in some other
>>> languages, if you call foo(3), and foo() changes the value of it's
>>> argument to 2, then subsequent calls to bar(3) will pass a value of 2 to
>>> bar().  That sounds like such a ridiculous mis-feature that I hesitate to
>>> identify which languages I had heard accused of having that feature ...
>>
>> I heard that, too.  I think it was on some early FORTRAN compilers, on
>> early machine architectures, without stacks or reentrancy.  And with the
>> weird FORTRAN argument-passing conventions.
>
> I remember it too, and was based on the fact that all arguments were
> pass by reference (so they could be either in or out parameters), and
> constants were passed as pointers to the location of memory where that
> constant was stored, and perhaps used elsewhere too.  Why waste
> precious memory to setup a temporary to hold be initialized and hold
> the value, when you could just pass the address of a location that you
> knew had the right value.

I think the original FORTRAN, and FORTRAN II, used call by reference.
In the early 1960s FORTRAN changed to using call by value-result
(which is similar to call by reference but slightly different).

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

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

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

csiph-web