Deutsch   English   Français   Italiano  
<86a5hh4gft.fsf@linuxsc.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: relearning C: why does an in-place change to a char* segfault?
Date: Mon, 12 Aug 2024 13:47:02 -0700
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <86a5hh4gft.fsf@linuxsc.com>
References: <IoGcndcJ1Zm83zb7nZ2dnZfqnPWdnZ2d@brightview.co.uk> <20240801114615.906@kylheku.com> <v8gs06$2ceis$1@dont-email.me> <20240801172148.200@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 12 Aug 2024 22:47:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f42e4005105099d89c60a754521770ce";
	logging-data="3643568"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/hnZoFrsh3JshIgcGjlAceFt+Y4S+BeTo="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:oJNQJH4Xfy74FW+3aZN9303ena0=
	sha1:cA40Xzc6ng2oADibpM+M/6xbHEU=
Bytes: 2385

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> On 2024-08-01, Bart <bc@freeuk.com> wrote:
>
>> On 01/08/2024 20:39, Kaz Kylheku wrote:
>>
>>> On 2024-08-01, Mark Summerfield <mark@qtrac.eu> 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";
>>>
>>> The "this is a test" object is a literal.  It is part of the
>>> program's image.
>>
>> So is the text here:
>>
>>    char text[]="this is a test";
>>
>> But this can be changed without making the program self-modifying.
>
> The array which is initialized by the literal is what can be
> changed.
>
> In this situation, the literal is just initializer syntax,
> not required to be an object with an address.

In the abstract machine I believe the initializing string
literal is required to be an object with an address.  The
discussion of string literals in 6.4.5 says there is such
an object for every string literal, and I don't see any
text in 6.7.9, covering Initialization, that overrules or
contradicts that.