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

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

Implicit String-Literal Concatenation

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

Contents

  Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 23:05 +0000
    Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-25 17:38 +0100
      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-25 20:43 +0000
        Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-25 21:20 +0000
    Re: Implicit String-Literal Concatenation Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-02-25 16:45 +0000
    Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-25 20:25 +0000
    Re: Implicit String-Literal Concatenation Łukasz 'Maly' Ostrowski <l3vi4than@gmail.com> - 2024-02-26 21:12 +0100
      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-26 20:31 +0000
        Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-27 13:18 +0100
          Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 23:10 +0000
            Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-28 00:50 +0100
    Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-26 20:42 +0000
    Re: Implicit String-Literal Concatenation porkchop@invalid.foo (Mike Sanders) - 2024-02-26 22:03 +0000
      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-26 23:17 +0000
        Re: Implicit String-Literal Concatenation porkchop@invalid.foo (Mike Sanders) - 2024-02-27 17:27 +0000
      Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-27 09:36 +0100
        Re: Implicit String-Literal Concatenation porkchop@invalid.foo (Mike Sanders) - 2024-02-27 17:31 +0000
        Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-27 18:56 +0000
          Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-27 23:21 +0100
            Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 22:52 +0000
              Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-28 01:09 +0000
                Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-28 12:50 +0100
                  Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-28 20:56 +0000
                    Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-28 21:34 +0000
                      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-28 23:52 +0000
                        Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 00:15 +0000
                          Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 02:53 +0000
                            Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 09:20 +0000
                          Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 15:48 +0000
                            Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-29 17:03 +0100
                              Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 16:17 +0000
                                Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-29 18:12 +0100
                                  Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 17:30 +0000
                                    Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 13:20 -0800
                                      Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 21:44 +0000
                                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 14:06 -0800
                                          Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 18:09 +0100
                                            Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-01 10:49 -0800
                                              Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 22:06 +0100
                                Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 09:20 -0800
                    Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 08:58 +0100
                      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 21:05 +0000
                        Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-03-01 09:16 +0100
                          Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-01 16:55 +0000
                            Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-03-01 18:28 +0100
        Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 20:25 +0000
          Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-27 12:35 -0800
            Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 23:03 +0000
          Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-27 22:12 +0000
            Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-28 12:54 +0100
              Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-28 13:13 +0000
                Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-28 15:08 +0100
                Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 13:36 -0800
                  Re: Implicit String-Literal Concatenation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-29 11:56 +0000
                    Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 16:19 +0100
                      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 21:36 +0000
                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 13:53 -0800
                        Re: Implicit String-Literal Concatenation Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-01 12:59 +0000
                          Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-01 20:59 +0000
                    Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 08:08 -0800
                  Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 14:31 +0000
                    Re: Implicit String-Literal Concatenation Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-29 15:22 +0000
                      Re: Implicit String-Literal Concatenation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-29 13:10 -0800
                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 13:45 -0800
                          Re: Implicit String-Literal Concatenation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-29 14:03 -0800
                            Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 14:14 -0800
                              Re: Implicit String-Literal Concatenation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-02 13:48 -0800
                              Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 04:48 +0000
                                Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 20:55 -0800
                                  Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-07 21:08 +0000
                                    Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-07 21:44 +0000
                                      Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-07 14:25 -0800
                                        Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-07 23:00 +0000
                                          Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-07 15:46 -0800
                                        Re: Implicit String-Literal Concatenation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-07 16:17 -0800
                                        Re: Implicit String-Literal Concatenation Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-08 00:26 +0000
                                    Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-07 14:16 -0800
                    Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 16:30 +0100
                      Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 08:25 -0800
                    Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 08:18 -0800
                      Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-29 18:17 +0100
                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 09:22 -0800
                          Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-29 19:26 +0000
                            Re: Implicit String-Literal Concatenation James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-29 14:45 -0500
                Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 13:41 -0800
              Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 13:57 -0800
                Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-28 23:01 +0000
                  Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 15:31 -0800
                    Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 00:47 +0000
                      Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 17:12 -0800
                      Re: Implicit String-Literal Concatenation tTh <tth@none.invalid> - 2024-02-29 16:29 +0100
                        Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 16:15 +0000
                      Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 15:53 +0000
                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 09:06 -0800
                          Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 17:28 +0000
                            Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 18:58 +0100
                              Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 18:05 +0000
                                Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 18:09 +0000
                                  Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 21:27 +0000
                                    Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-03-01 11:52 +0000
                                      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 04:47 +0000
                                        Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-03-05 15:09 +0000
                                          Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-06 01:49 +0000
                                Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 20:51 +0100
                Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 10:10 +0100
                  Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 10:18 +0000
                    Re: Implicit String-Literal Concatenation tTh <tth@none.invalid> - 2024-02-29 16:34 +0100
                      Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-03-01 11:58 +0000
                        Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-03-01 13:17 +0100
                  Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 09:03 -0800
                    Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 19:08 +0100

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

#383163

On 28/02/2024 21:36, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> AFAIK strings in C can have embedded zeros when not assumed to be
>> zero-terminated. So here:
>>
>>      char s[]={1,2,3,0,4,5,6};
>>
>> s will have a length of 7.
> 
> Strings *by definition* cannot have embedded zeros.  A null character
> terminates a string.
> 
> A string literal can have embedded \0 characters, but if you're
> suggesting that #embed should expand to a string literal, I can see
> several disadvantages and no significant advantages.  For one thing, the
> data may or may not end with a null character; string literals always
> do.

Not here:

     char s[]  = "ABC";
     char t[3] = "DEF";

The "DEF" string doesn't end with a zero.

Is 'string' given a special meaning in the standard?

/That/ would seem to me to be too restrictive. Does this:

    char *s;

define a pointer to a such string, or can it be any kind of data? For 
example, `char*` is used by the GetOpenFileName WinAPI function for a 
/series/ of zero-terminated strings which itself is terminated with two 
zero bytes.

So it is some property that is attributed to the data that will be stored.

I normally use `cstring` or `stringz` outside the language when refering 
to a zero-terminated sequences of characters, which implies that 
embedded zeros aren't allowed.

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

#383166

On 29/02/2024 14:31, bart wrote:
> On 28/02/2024 21:36, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> AFAIK strings in C can have embedded zeros when not assumed to be
>>> zero-terminated. So here:
>>>
>>>      char s[]={1,2,3,0,4,5,6};
>>>
>>> s will have a length of 7.
>>
>> Strings *by definition* cannot have embedded zeros.  A null character
>> terminates a string.
>>
>> A string literal can have embedded \0 characters, but if you're
>> suggesting that #embed should expand to a string literal, I can see
>> several disadvantages and no significant advantages.  For one thing, the
>> data may or may not end with a null character; string literals always
>> do.
> 
> Not here:
> 
>      char s[]  = "ABC";
>      char t[3] = "DEF";
> 
> The "DEF" string doesn't end with a zero.

And is, therefore, not a string.

> 
> Is 'string' given a special meaning in the standard?

Yes.  Things that work with the strX functions.  Which means they are 
'\0' terminated.

> 
> /That/ would seem to me to be too restrictive. Does this:
> 
>     char *s;
> 
> define a pointer to a such string, or can it be any kind of data? For 

That points to a char.  That could be followed by more chars and it one 
of those is a '\0', then it's a string.  You know this.


> example, `char*` is used by the GetOpenFileName WinAPI function for a 
> /series/ of zero-terminated strings which itself is terminated with two 
> zero bytes.

That is a windowsism, then.

Why didn't they use the NULL terminated char **argv kind of thing?

> 
> So it is some property that is attributed to the data that will be stored.
> 
> I normally use `cstring` or `stringz` outside the language when refering 
> to a zero-terminated sequences of characters, which implies that 
> embedded zeros aren't allowed.
> 
> 
> 
> 

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

#383196

On 2/29/2024 7:22 AM, Richard Harnden wrote:
> On 29/02/2024 14:31, bart wrote:
>> On 28/02/2024 21:36, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>> [...]
>>>> AFAIK strings in C can have embedded zeros when not assumed to be
>>>> zero-terminated. So here:
>>>>
>>>>      char s[]={1,2,3,0,4,5,6};
>>>>
>>>> s will have a length of 7.
>>>
>>> Strings *by definition* cannot have embedded zeros.  A null character
>>> terminates a string.
>>>
>>> A string literal can have embedded \0 characters, but if you're
>>> suggesting that #embed should expand to a string literal, I can see
>>> several disadvantages and no significant advantages.  For one thing, the
>>> data may or may not end with a null character; string literals always
>>> do.
>>
>> Not here:
>>
>>      char s[]  = "ABC";
>>      char t[3] = "DEF";
>>
>> The "DEF" string doesn't end with a zero.
> 
> And is, therefore, not a string.
[...]

Right. However, is this a string or two embedded strings:

char x[] = "ABC\0DEF"
_____________________
#include <stdio.h>

int main()
{
     char x[] = "ABC\0DEF";

     printf("%s\n", x);
     printf("%s", x + 4);

     return 0;
}
_____________________

Any undefined behavior here?

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

#383202

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 2/29/2024 7:22 AM, Richard Harnden wrote:
>> On 29/02/2024 14:31, bart wrote:
[...]
>>> Not here:
>>>
>>>      char s[]  = "ABC";
>>>      char t[3] = "DEF";
>>>
>>> The "DEF" string doesn't end with a zero.
>> And is, therefore, not a string.
> [...]
>
> Right. However, is this a string or two embedded strings:
>
> char x[] = "ABC\0DEF"

Is *what* a string or two embedded strings?

x as a whole does not contain a string, but there are 8 strings within it.

> _____________________
> #include <stdio.h>
>
> int main()
> {
>     char x[] = "ABC\0DEF";
>
>     printf("%s\n", x);
>     printf("%s", x + 4);
>
>     return 0;
> }
> _____________________
>
> Any undefined behavior here?

No, and none in this:

    for (size_t i = 0; i < sizeof x; i ++) {
        printf("%s\n", x+i);
    }

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

#383204

On 2/29/2024 1:45 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 2/29/2024 7:22 AM, Richard Harnden wrote:
>>> On 29/02/2024 14:31, bart wrote:
> [...]
>>>> Not here:
>>>>
>>>>       char s[]  = "ABC";
>>>>       char t[3] = "DEF";
>>>>
>>>> The "DEF" string doesn't end with a zero.
>>> And is, therefore, not a string.
>> [...]
>>
>> Right. However, is this a string or two embedded strings:
>>
>> char x[] = "ABC\0DEF"
^^^^^^^^^^^^^^^^^^^^^


> 
> Is *what* a string or two embedded strings?

For some reason, I see two "embedded" "C strings" wrt null termination here.


> x as a whole does not contain a string, but there are 8 strings within it.

Well, I was referring to that null terminator. So I see two "C strings" 
separated by an offset? Wrt using std functions that terminate on a '\0'?

I think I am misunderstanding you. Sorry... ;^o



> 
>> _____________________
>> #include <stdio.h>
>>
>> int main()
>> {
>>      char x[] = "ABC\0DEF";
>>
>>      printf("%s\n", x);
>>      printf("%s", x + 4);
>>
>>      return 0;
>> }
>> _____________________
>>
>> Any undefined behavior here?
> 
> No, and none in this:
> 
>      for (size_t i = 0; i < sizeof x; i ++) {
>          printf("%s\n", x+i);
>      }
> 

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

#383206

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 2/29/2024 1:45 PM, Keith Thompson wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 2/29/2024 7:22 AM, Richard Harnden wrote:
>>>> On 29/02/2024 14:31, bart wrote:
>> [...]
>>>>> Not here:
>>>>>
>>>>>       char s[]  = "ABC";
>>>>>       char t[3] = "DEF";
>>>>>
>>>>> The "DEF" string doesn't end with a zero.
>>>> And is, therefore, not a string.
>>> [...]
>>>
>>> Right. However, is this a string or two embedded strings:
>>>
>>> char x[] = "ABC\0DEF"
> ^^^^^^^^^^^^^^^^^^^^^
>
>> Is *what* a string or two embedded strings?
>
> For some reason, I see two "embedded" "C strings" wrt null termination here.

I was asking you to clarify what you're referring to.  What you posted
is a declaration, not a string.  You could have been referring to the
object x, to the string literal, to subsets of either, or to something else.

>> x as a whole does not contain a string, but there are 8 strings within it.
>
> Well, I was referring to that null terminator. So I see two "C
> strings" separated by an offset? Wrt using std functions that
> terminate on a '\0'?
>
> I think I am misunderstanding you. Sorry... ;^o

I thought I explained it, but here's a more straightforward explanation.
And the term "string" is defined by 7.1.1p1, not by the behavior of
standard functions: "A *string* is a contiguous sequence of characters
terminated by and including the first null character."

At run time, the array `x` contains:
- A string of length 3 starting at index 0.
- A string of length 2 starting at index 1.
- A string of length 1 starting at index 2.
- A string of length 0 starting at index 3.
- A string of length 3 starting at index 4.
- A string of length 2 starting at index 5.
- A string of length 1 starting at index 6.
- A string of length 0 starting at index 7.

#include <stdio.h>
int main(void) {
    char x[] = "ABC\0DEF";
    for (size_t i = 0; i < sizeof x; i ++) {
        printf("x[%zu] is a pointer to the string \"%s\"\n", i, x+i);
    }
}

Output:
x[0] is a pointer to the string "ABC"
x[1] is a pointer to the string "BC"
x[2] is a pointer to the string "C"
x[3] is a pointer to the string ""
x[4] is a pointer to the string "DEF"
x[5] is a pointer to the string "EF"
x[6] is a pointer to the string "F"
x[7] is a pointer to the string ""

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

#383246

On 2/29/2024 2:14 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 2/29/2024 1:45 PM, Keith Thompson wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 2/29/2024 7:22 AM, Richard Harnden wrote:
>>>>> On 29/02/2024 14:31, bart wrote:
>>> [...]
>>>>>> Not here:
>>>>>>
>>>>>>        char s[]  = "ABC";
>>>>>>        char t[3] = "DEF";
>>>>>>
>>>>>> The "DEF" string doesn't end with a zero.
>>>>> And is, therefore, not a string.
>>>> [...]
>>>>
>>>> Right. However, is this a string or two embedded strings:
>>>>
>>>> char x[] = "ABC\0DEF"
>> ^^^^^^^^^^^^^^^^^^^^^
>>
>>> Is *what* a string or two embedded strings?
>>
>> For some reason, I see two "embedded" "C strings" wrt null termination here.
> 
> I was asking you to clarify what you're referring to.  What you posted
> is a declaration, not a string.  You could have been referring to the
> object x, to the string literal, to subsets of either, or to something else.
> 
>>> x as a whole does not contain a string, but there are 8 strings within it.
>>
>> Well, I was referring to that null terminator. So I see two "C
>> strings" separated by an offset? Wrt using std functions that
>> terminate on a '\0'?
>>
>> I think I am misunderstanding you. Sorry... ;^o
> 
> I thought I explained it, but here's a more straightforward explanation.
> And the term "string" is defined by 7.1.1p1, not by the behavior of
> standard functions: "A *string* is a contiguous sequence of characters
> terminated by and including the first null character."
[...]

Ahhh yes. Sorry for glossing over that point.

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

#383365

On Thu, 29 Feb 2024 14:14:52 -0800, Keith Thompson wrote:

> "A *string* is a contiguous sequence of characters
> terminated by and including the first null character."

So how come strlen(3) does not include the null?

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

#383366

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 29 Feb 2024 14:14:52 -0800, Keith Thompson wrote:
>> "A *string* is a contiguous sequence of characters
>> terminated by and including the first null character."
>
> So how come strlen(3) does not include the null?

Because the *length of a string* is by definition "the number of bytes
preceding the null character".

Why is it defined that way?  Because it's more useful than the
alternative.

See 7.1.1 paragraph 1 in any edition or draft of the C standard.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

#383457

On Mon, 04 Mar 2024 20:55:28 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Thu, 29 Feb 2024 14:14:52 -0800, Keith Thompson wrote:
>>
>>> "A *string* is a contiguous sequence of characters terminated by and
>>> including the first null character."
>>
>> So how come strlen(3) does not include the null?
> 
> Because the *length of a string* is by definition "the number of bytes
> preceding the null character".

So the “string” itself includes the null character, but its “length” does 
not?

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

#383458

On 2024-03-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 04 Mar 2024 20:55:28 -0800, Keith Thompson wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Thu, 29 Feb 2024 14:14:52 -0800, Keith Thompson wrote:
>>>
>>>> "A *string* is a contiguous sequence of characters terminated by and
>>>> including the first null character."
>>>
>>> So how come strlen(3) does not include the null?
>> 
>> Because the *length of a string* is by definition "the number of bytes
>> preceding the null character".
>
> So the “string” itself includes the null character, but its “length” does 
> not?

That's correct. However, its size includes it.

 sizeof "abc" == 4

 strlen("abc") == 3

The abstract string does not include the null character;
we understand "abc" to be a three character string.

The C representation of the string includes the null character;
the size is a representational concept so it counts it.

It is common for C programs to break encapsulation and openly deal with
that terminating null.

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

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

#383460

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-03-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Mon, 04 Mar 2024 20:55:28 -0800, Keith Thompson wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> On Thu, 29 Feb 2024 14:14:52 -0800, Keith Thompson wrote:
>>>>> "A *string* is a contiguous sequence of characters terminated by and
>>>>> including the first null character."
>>>>
>>>> So how come strlen(3) does not include the null?
>>> 
>>> Because the *length of a string* is by definition "the number of bytes
>>> preceding the null character".
>>
>> So the “string” itself includes the null character, but its “length” does 
>> not?
>
> That's correct. However, its size includes it.
>
>  sizeof "abc" == 4
>
>  strlen("abc") == 3
>
> The abstract string does not include the null character;
> we understand "abc" to be a three character string.

Sure, if you define "abstract string" that way.  I'll just note that C's
definition of the word "string" does include the terminating null
character, and does not talk about "abstract strings".  (A string in the
abstract machine clearly includes the null character, but that's a bit
of a stretch.)

Yes, I'm being annoyingly pedantic.

> The C representation of the string includes the null character;
> the size is a representational concept so it counts it.
>
> It is common for C programs to break encapsulation and openly deal with
> that terminating null.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

#383461

On 2024-03-07, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2024-03-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Mon, 04 Mar 2024 20:55:28 -0800, Keith Thompson wrote:
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>> On Thu, 29 Feb 2024 14:14:52 -0800, Keith Thompson wrote:
>>>>>> "A *string* is a contiguous sequence of characters terminated by and
>>>>>> including the first null character."
>>>>>
>>>>> So how come strlen(3) does not include the null?
>>>> 
>>>> Because the *length of a string* is by definition "the number of bytes
>>>> preceding the null character".
>>>
>>> So the “string” itself includes the null character, but its “length” does 
>>> not?
>>
>> That's correct. However, its size includes it.
>>
>>  sizeof "abc" == 4
>>
>>  strlen("abc") == 3
>>
>> The abstract string does not include the null character;
>> we understand "abc" to be a three character string.
>
> Sure, if you define "abstract string" that way.  I'll just note that C's
> definition of the word "string" does include the terminating null
> character, and does not talk about "abstract strings".  (A string in the
> abstract machine clearly includes the null character, but that's a bit
> of a stretch.)

Yes; "abstract machine" is not what I mean by abstract.

The concept of the abstract string lives in the semantics though.

When N strings are catenated together, their abstract strings are
juxtaposed together without any nulls in between, with only a single
null at the end.

Furthermore, when a string is sent to a stream with %s or {f}puts,
the null byte is omitted, like in the calculation of length.

Clearly, there is a semantics that the part before the null byte
is the text processing payload; what I'm calling the abstract string.

(With character encodings, it gets hairy. The part before the null
may be a UTF-8 sequence, where the abstract string consists of code
points. Which may be combining characters, so the True Scotsman's
abstract string is the sequence of characters.)
-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#383465

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-03-07, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>> On 2024-03-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> On Mon, 04 Mar 2024 20:55:28 -0800, Keith Thompson wrote:
>>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>>> On Thu, 29 Feb 2024 14:14:52 -0800, Keith Thompson wrote:
>>>>>>> "A *string* is a contiguous sequence of characters terminated by and
>>>>>>> including the first null character."
>>>>>>
>>>>>> So how come strlen(3) does not include the null?
>>>>> 
>>>>> Because the *length of a string* is by definition "the number of bytes
>>>>> preceding the null character".
>>>>
>>>> So the “string” itself includes the null character, but its “length” does 
>>>> not?
>>>
>>> That's correct. However, its size includes it.
>>>
>>>  sizeof "abc" == 4
>>>
>>>  strlen("abc") == 3
>>>
>>> The abstract string does not include the null character;
>>> we understand "abc" to be a three character string.
>>
>> Sure, if you define "abstract string" that way.  I'll just note that C's
>> definition of the word "string" does include the terminating null
>> character, and does not talk about "abstract strings".  (A string in the
>> abstract machine clearly includes the null character, but that's a bit
>> of a stretch.)
>
> Yes; "abstract machine" is not what I mean by abstract.
>
> The concept of the abstract string lives in the semantics though.
>
> When N strings are catenated together, their abstract strings are
> juxtaposed together without any nulls in between, with only a single
> null at the end.

True both for compile-time string literal catenation and for strcat().

But for the former, embedded null characters can slightly complicate
matters.  The value of a string literal isn't necessarily a string.

#include <stdio.h>
int main(void) {
    const char s[] = "abc\0def" "ghi\0";
    puts(s);
    for (size_t i = 0; i < sizeof s; i ++) {
        if (s[i] == '\0') {
            fputs("\\0", stdout);
        }
        else {
            putchar(s[i]);
        }
    }
    putchar('\n');
}

Output:
abc
abc\0defghi\0\0

> Furthermore, when a string is sent to a stream with %s or {f}puts,
> the null byte is omitted, like in the calculation of length.
>
> Clearly, there is a semantics that the part before the null byte
> is the text processing payload; what I'm calling the abstract string.

Agreed.  To be clear, I like the idea of referring to the contents of a
string excluding the terminating null character as an "abstract string".

> (With character encodings, it gets hairy. The part before the null
> may be a UTF-8 sequence, where the abstract string consists of code
> points. Which may be combining characters, so the True Scotsman's
> abstract string is the sequence of characters.)

Yes.  With UTF-8, the term "abstract string" might reasonably refer
either to the sequence of bytes preceding the terminating '\0', or to
the sequence of code points.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

#383466

On 3/7/2024 2:25 PM, Keith Thompson wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2024-03-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Mon, 04 Mar 2024 20:55:28 -0800, Keith Thompson wrote:
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>> On Thu, 29 Feb 2024 14:14:52 -0800, Keith Thompson wrote:
>>>>>> "A *string* is a contiguous sequence of characters terminated by and
>>>>>> including the first null character."
>>>>>
>>>>> So how come strlen(3) does not include the null?
>>>>
>>>> Because the *length of a string* is by definition "the number of bytes
>>>> preceding the null character".
>>>
>>> So the “string” itself includes the null character, but its “length” does
>>> not?
>>
>> That's correct. However, its size includes it.
>>
>>   sizeof "abc" == 4
>>
>>   strlen("abc") == 3
>>
>> The abstract string does not include the null character;
>> we understand "abc" to be a three character string.
> 
> Sure, if you define "abstract string" that way.  I'll just note that C's
> definition of the word "string" does include the terminating null
> character, and does not talk about "abstract strings".  (A string in the
> abstract machine clearly includes the null character, but that's a bit
> of a stretch.)
> 
> Yes, I'm being annoyingly pedantic.

:^D The ADA vs Ada was a little pedantic, so to speak. ;^)


> 
>> The C representation of the string includes the null character;
>> the size is a representational concept so it counts it.
>>
>> It is common for C programs to break encapsulation and openly deal with
>> that terminating null.
> 

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

#383468

On 07/03/2024 22:25, Keith Thompson wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2024-03-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Mon, 04 Mar 2024 20:55:28 -0800, Keith Thompson wrote:
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>> On Thu, 29 Feb 2024 14:14:52 -0800, Keith Thompson wrote:
>>>>>> "A *string* is a contiguous sequence of characters terminated by and
>>>>>> including the first null character."
>>>>>
>>>>> So how come strlen(3) does not include the null?
>>>>
>>>> Because the *length of a string* is by definition "the number of bytes
>>>> preceding the null character".
>>>
>>> So the “string” itself includes the null character, but its “length” does
>>> not?
>>
>> That's correct. However, its size includes it.
>>
>>   sizeof "abc" == 4
>>
>>   strlen("abc") == 3
>>
>> The abstract string does not include the null character;
>> we understand "abc" to be a three character string.
> 
> Sure, if you define "abstract string" that way.  I'll just note that C's
> definition of the word "string" does include the terminating null
> character, and does not talk about "abstract strings".  (A string in the
> abstract machine clearly includes the null character, but that's a bit
> of a stretch.)

A string is just a data format.

You have a string of chars, terminated by a '\0'.

You can have a "string" of anything, terminated by a NULL.
Everyone's used to argv, for example.

> 
> Yes, I'm being annoyingly pedantic.
> 
>> The C representation of the string includes the null character;
>> the size is a representational concept so it counts it.
>>
>> It is common for C programs to break encapsulation and openly deal with
>> that terminating null.
> 

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

#383459

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 04 Mar 2024 20:55:28 -0800, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Thu, 29 Feb 2024 14:14:52 -0800, Keith Thompson wrote:
>>>> "A *string* is a contiguous sequence of characters terminated by and
>>>> including the first null character."
>>>
>>> So how come strlen(3) does not include the null?
>> 
>> Because the *length of a string* is by definition "the number of bytes
>> preceding the null character".
>
> So the “string” itself includes the null character, but its “length” does 
> not?

Yes, as you can easily see if you read 7.1.1p1 for yourself.

I can't tell if you're trying to understand C strings, or you're
suprised by how they're defined, or you object to how they're defined,
or you don't accept how they're defined, or something else.  I'm getting
the impression that you're arguing for the sake of arguing, but perhaps
that's unfair of me.  If you have a wider point, perhaps you could let
us know what it is.

I'll also note that you asked why strlen() doesn't include the null, I
answered, and you snipped most of my answer.  Of course there's usually
no need to quote all of an article you're replying to, but it would be
helpful if you'd mark your deletions.  (I usually use "[...]".)  You've
given the impression that I gave you just a one-sentence answer to your
question, which is not the case.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

#383168

On 29/02/2024 15:31, bart wrote:
> On 28/02/2024 21:36, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> AFAIK strings in C can have embedded zeros when not assumed to be
>>> zero-terminated. So here:
>>>
>>>      char s[]={1,2,3,0,4,5,6};
>>>
>>> s will have a length of 7.
>>
>> Strings *by definition* cannot have embedded zeros.  A null character
>> terminates a string.
>>
>> A string literal can have embedded \0 characters, but if you're
>> suggesting that #embed should expand to a string literal, I can see
>> several disadvantages and no significant advantages.  For one thing, the
>> data may or may not end with a null character; string literals always
>> do.
> 
> Not here:
> 
>      char s[]  = "ABC";

"ABC" is a "string literal".  Once things like concatenation of adjacent 
strings, macro expansion, etc., is complete, a null character is 
appended to it.  Then it is used as an initialiser for the array "s". 
After initialisation, "s" is an array of 4 chars and contains a string.

(Note - a "string literal" might not be a "string", because string 
literals can contain embedded nulls.  This is a footnote in 6.4.5 
describing string literals.)

>      char t[3] = "DEF";
> 
> The "DEF" string doesn't end with a zero.

"DEF" is not a "string" - it is a "string literal".  It does get a null 
character appended during translation phase 7.  But only the first three 
characters - therefore not including the null character - get copied to 
"t" during the initialisation of "t".  "t" is an array of 3 chars, and 
it does not contain a string.

> 
> Is 'string' given a special meaning in the standard?
> 

Yes.  See 7.1.1p1.

> /That/ would seem to me to be too restrictive. Does this:
> 
>     char *s;
> 
> define a pointer to a such string, or can it be any kind of data? For 
> example, `char*` is used by the GetOpenFileName WinAPI function for a 
> /series/ of zero-terminated strings which itself is terminated with two 
> zero bytes.
> 

"char *s;" declares a pointer to a char, or a pointer to the start of an 
array of char.  It is /not/ a string, or a pointer to a string.  C 
strings are values, and exist at run-time - they are not types.  So "s" 
can point to a string, or a char (which will be a string if and only if 
it is a null character), or an array of chars (which may or may not 
contain a string), or it could point to anything else.

> So it is some property that is attributed to the data that will be stored.

Yes.

> 
> I normally use `cstring` or `stringz` outside the language when refering 
> to a zero-terminated sequences of characters, which implies that 
> embedded zeros aren't allowed.
> 

That makes sense.  Different languages have different ways of holding 
sequences of characters (generic "string" data), so you need to qualify 
the term if it is not clear from the context.

But when we are discussing C, and there is no other qualification, 
"string" means "C string" - the definition of "string" given in the C 
standards.

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

#383178

David Brown <david.brown@hesbynett.no> writes:
[...]
> "char *s;" declares a pointer to a char, or a pointer to the start of
> an array of char.

"char *s;" defines a pointer to char.  At runtime, it may or may not
point to the initial element of an array object.  (And for most
purposes, a char object is treated as 1-element array of char.)

>                    It is /not/ a string, or a pointer to a string.

It may be a pointer to a string at run time, depending on what it
currently points to.

> C strings are values, and exist at run-time - they are not types.  So
> "s" can point to a string, or a char (which will be a string if and
> only if it is a null character), or an array of chars (which may or
> may not contain a string), or it could point to anything else.

"s" can point to *the initial element of* an array of chars.  if that
array contains a string, then (the value of) s is by definition a
pointer to a string.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

#383177

bart <bc@freeuk.com> writes:
> On 28/02/2024 21:36, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> AFAIK strings in C can have embedded zeros when not assumed to be
>>> zero-terminated. So here:
>>>
>>>      char s[]={1,2,3,0,4,5,6};
>>>
>>> s will have a length of 7.
>> Strings *by definition* cannot have embedded zeros.  A null
>> character
>> terminates a string.
>> A string literal can have embedded \0 characters, but if you're
>> suggesting that #embed should expand to a string literal, I can see
>> several disadvantages and no significant advantages.  For one thing, the
>> data may or may not end with a null character; string literals always
>> do.
>
> Not here:
>
>     char s[]  = "ABC";
>     char t[3] = "DEF";
>
> The "DEF" string doesn't end with a zero.

That's not strictly true, nor is it relevant.

For #embed, you generally don't know the length of the resulting
sequence of values, so you can't usually write something like:

    const unsigned char data[N] = {
#embed "foo.dat"
    };

And the way it's described in the standard is that "DEF" refers to an
array object that does include a trailing null byte, but only the first
3 characters are used to initialize t.  Of course a compiler can
optimize that one byte away.

> Is 'string' given a special meaning in the standard?

Of course it is.  Surely you know that.  7.1.1 paragraph 1.

"abc\0def" is a valid string literal, but its value is not a string.
(No, the standard doesn't say that the value of a string literal is a
string.)

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

[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