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

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

C String terminator

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

Contents

  C String terminator T <T@invalid.invalid> - 2020-01-14 09:22 -0800
    Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-14 09:32 -0800
      Re: C String terminator T <T@invalid.invalid> - 2020-01-14 09:43 -0800
        Re: C String terminator Bart <bc@freeuk.com> - 2020-01-14 17:53 +0000
          Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-01-14 20:17 +0100
            Re: C String terminator Bart <bc@freeuk.com> - 2020-01-14 20:01 +0000
        Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-14 09:57 -0800
          Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-14 11:37 -0800
            Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:02 -0800
              Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:38 -0800
                Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:53 -0800
          Re: C String terminator Manfred <noname@add.invalid> - 2020-01-14 20:48 +0100
      Re: C String terminator chad <cdalten@gmail.com> - 2020-01-15 05:43 -0800
        Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-15 07:12 -0800
        Re: C String terminator Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-15 15:35 +0000
          Re: C String terminator chad <cdalten@gmail.com> - 2020-01-19 06:20 -0800
      Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 10:52 -0800
        Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-15 12:52 -0800
          Re: C String terminator gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-15 20:56 +0000
          Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 02:17 +0000
          Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 21:54 -0800
            Re: C String terminator fir <profesor.fir@gmail.com> - 2020-01-16 02:07 -0800
              Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-16 02:45 -0800
                Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-16 08:21 -0700
                  Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-16 08:03 -0800
                Re: C String terminator John Bode <jfbode1029@gmail.com> - 2020-01-16 09:06 -0800
                Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-16 11:29 -0800
        Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 02:01 +0000
          Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-15 23:02 -0500
          Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-01-16 11:15 +0100
            Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 13:07 +0000
          Re: C String terminator Manfred <noname@add.invalid> - 2020-01-17 18:43 +0100
            Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 04:00 -0800
            Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 05:00 -0800
    Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-14 12:36 -0700
      Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-14 12:05 -0800
        Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-14 13:54 -0700
          Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-14 15:03 -0800
            Re: C String terminator Thiago Adams <thiago.adams@gmail.com> - 2020-01-15 04:55 -0800
              Re: C String terminator Guillaume <message@bottle.org> - 2020-01-15 20:49 +0100
                Re: C String terminator Thiago Adams <thiago.adams@gmail.com> - 2020-01-15 12:55 -0800
          Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-14 21:31 -0800
      Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:28 -0800
        Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:38 -0800
          Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-15 10:50 -0700
            Re: C String terminator T <T@invalid.invalid> - 2020-01-15 10:17 -0800
          Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:53 -0800
    Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-01-14 21:43 -0500
    Re: C String terminator "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-14 22:52 -0800
      Re: C String terminator "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-14 22:54 -0800
    Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 02:00 -0800
      Re: C String terminator gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-15 10:47 +0000
        Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-15 03:02 -0800
      Re: C String terminator T <T@invalid.invalid> - 2020-01-15 10:19 -0800
        Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 11:33 -0800
          Re: C String terminator T <T@invalid.invalid> - 2020-01-15 12:03 -0800
            Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 01:30 +0000
              Re: C String terminator T <T@invalid.invalid> - 2020-01-15 18:17 -0800
                Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 03:44 +0000
                  Re: C String terminator T <T@invalid.invalid> - 2020-01-15 20:33 -0800
            Re: C String terminator fir <profesor.fir@gmail.com> - 2020-01-16 02:26 -0800
    Re: C String terminator Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-15 15:11 +0000
      Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:32 -0800
        Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 10:47 -0800
          Re: C String terminator T <T@invalid.invalid> - 2020-01-15 10:58 -0800
            Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 01:39 +0000
              Re: C String terminator T <T@invalid.invalid> - 2020-01-15 18:27 -0800
                Re: C String terminator T <T@invalid.invalid> - 2020-01-15 19:03 -0800
                Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 03:28 +0000
                  Re: C String terminator T <T@invalid.invalid> - 2020-01-15 19:33 -0800
                  Re: C String terminator T <T@invalid.invalid> - 2020-01-15 19:38 -0800
                    Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 13:31 +0000
                      Re: C String terminator T <T@invalid.invalid> - 2020-01-16 09:09 -0800
                        Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-16 10:27 -0700
                          Re: C String terminator T <T@invalid.invalid> - 2020-01-16 10:54 -0800
                            Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 20:59 +0000
                              Re: C String terminator T <T@invalid.invalid> - 2020-01-16 14:11 -0800
                          Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 20:17 +0000
                            Re: C String terminator T <T@invalid.invalid> - 2020-01-16 14:14 -0800
                              Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 23:45 +0000
                                Yes, Ben makes house calls (Was: C String terminator) gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-16 23:57 +0000
                                Re: C String terminator T <T@invalid.invalid> - 2020-01-17 11:28 -0800
                                  Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-17 20:46 +0000
                                    Re: C String terminator T <T@invalid.invalid> - 2020-01-17 12:48 -0800
                                      Re: C String terminator T <T@invalid.invalid> - 2020-01-17 12:54 -0800
                                        Re: C String terminator Bart <bc@freeuk.com> - 2020-01-17 21:02 +0000
                                          Re: C String terminator Bart <bc@freeuk.com> - 2020-01-17 21:21 +0000
                                            Re: C String terminator T <T@invalid.invalid> - 2020-01-17 13:35 -0800
                                              Re: C String terminator T <T@invalid.invalid> - 2020-01-17 13:44 -0800
                                            Re: C String terminator fir <profesor.fir@gmail.com> - 2020-01-17 15:03 -0800
                                              Re: C String terminator fir <profesor.fir@gmail.com> - 2020-01-17 15:06 -0800
                                            Re: C String terminator Ike Naar <ike@sdf.lonestar.org> - 2020-01-18 07:30 +0000
                                        Re: C String terminator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-17 16:06 -0500
                                          Re: C String terminator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-17 16:23 -0500
                                            Re: C String terminator T <T@invalid.invalid> - 2020-01-17 13:37 -0800
                                            Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 04:10 -0800
                                              Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-21 10:41 -0800
                              Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-17 01:55 -0800
                                Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-17 09:52 -0800
                                  Re: C String terminator T <T@invalid.invalid> - 2020-01-17 11:29 -0800
                        Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 18:21 +0000
                          Re: C String terminator T <T@invalid.invalid> - 2020-01-16 10:50 -0800
                            Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 20:50 +0000
                              Re: C String terminator T <T@invalid.invalid> - 2020-01-16 14:17 -0800
    Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 09:59 -0800
    Re: C String terminator T <T@invalid.invalid> - 2020-01-15 10:15 -0800
    Re: C String terminator T <T@invalid.invalid> - 2020-01-18 21:42 -0800
      Re: C String terminator T <T@invalid.invalid> - 2020-01-19 22:13 -0800
    Re: C String terminator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-21 19:49 +0100
    Re: C String terminator John Bode <jfbode1029@gmail.com> - 2020-01-21 15:33 -0800
      Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-21 23:19 -0800
      Re: C String terminator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 08:39 +0100
        Re: C String terminator chad <cdalten@gmail.com> - 2020-01-22 06:59 -0800
          Re: C String terminator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 18:44 +0100

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

#149211 — Yes, Ben makes house calls (Was: C String terminator)

In article <877e1rc6f7.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
...
>I don't know.  That depends on your compiler, OS and so on and that
>obviously different to mine sice whole process of compiling and running
>is shown above.

I think with T, you're going to have to go to his house and show him how to
compile and run the program.  Nothing else will do.

-- 
    The difference between communism and capitalism?
    In capitalism, man exploits man. In communism, it's the other way around.

	- Daniel Bell, The End of Ideology (1960) -

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

#149229

On 2020-01-16 15:45, Ben Bacarisse wrote:
> T <T@invalid.invalid> writes:
> 
>> On 2020-01-16 12:17, Ben Bacarisse wrote:
>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>>
>>>> T <T@invalid.invalid> writes:
>>>>
>>>>> On 2020-01-16 05:31, Ben Bacarisse wrote:
>>>>>> You have not yet achieved your goal!  Can you submit a patch to the
>>>>>> documentation?
>>>>>
>>>>> I got shot down by the first responder before I even
>>>>> got that far.  If the example works, then there is
>>>>> not bug.  The correspondence was with him
>>>>
>>>> Then you need to concoct a simple example that does not work.
>>>
>>> That's not always easy.  I may be very hard indeed.  Here's a C example:
>>>
>>> $ cat t.c
>>> #include <stdio.h>
>>>
>>> void foo(const char *s)
>>> {
>>>        printf("[%s]\n", s);
>>> }
>>>
>>> int main(void)
>>> {
>>>        char str[3] = "FOO";
>>>        foo(str); // DANGER, WILL ROBINSON!
>>> }
>>> $ gcc -o t t.c
>>> $ ./t
>>> [FOO]
>>>
>>> All must be well because it works!  It's even harder when the C function
>>> is called from a high-level language where there is far less chance to
>>> control data layout etc.
>>>
>>> People should accept a simple, well-argued claim that something is
>>> wrong.
>>>
>> I am a total idiot when it comes to C.  How do
>> I run this?
> 
> I don't know.  That depends on your compiler, OS and so on and that
> obviously different to mine sice whole process of compiling and running
> is shown above.

I have Fedora Linux at my disposal, which has
a gcc c compiler.

Nothing I know of on the Windows side.

> 
>> Does char str[3] = "FOO"; mean there cells (bytes?)
>> or 4 [0..3]?
> 
> char is C's name for a byte.  The number in an array type is the number
> of objects in the array, so str is an array or three bytes, indexed from
> 0 to 2 inclusive.
> 

:-)

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

#149232

T <T@invalid.invalid> writes:

> On 2020-01-16 15:45, Ben Bacarisse wrote:
>> T <T@invalid.invalid> writes:
>>
>>> On 2020-01-16 12:17, Ben Bacarisse wrote:
<cut>
>>>> $ gcc -o t t.c
>>>> $ ./t
<cut>
>>> I am a total idiot when it comes to C.  How do
>>> I run this?
>>
>> I don't know.  That depends on your compiler, OS and so on and that
>> obviously different to mine sice whole process of compiling and running
>> is shown above.
>
> I have Fedora Linux at my disposal, which has
> a gcc c compiler.

Then I am baffled.  I showed both the gcc command to compile the code,
and the command to run it.  I've removed everything else so you can see
them.

<cut>
-- 
Ben.

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

#149233

On 2020-01-17 12:46, Ben Bacarisse wrote:
> T <T@invalid.invalid> writes:
> 
>> On 2020-01-16 15:45, Ben Bacarisse wrote:
>>> T <T@invalid.invalid> writes:
>>>
>>>> On 2020-01-16 12:17, Ben Bacarisse wrote:
> <cut>
>>>>> $ gcc -o t t.c
>>>>> $ ./t
> <cut>
>>>> I am a total idiot when it comes to C.  How do
>>>> I run this?
>>>
>>> I don't know.  That depends on your compiler, OS and so on and that
>>> obviously different to mine sice whole process of compiling and running
>>> is shown above.
>>
>> I have Fedora Linux at my disposal, which has
>> a gcc c compiler.
> 
> Then I am baffled.  I showed both the gcc command to compile the code,
> and the command to run it.  I've removed everything else so you can see
> them.
> 
> <cut>
> 

Ben!  I am an idiot when it comes to C.  You
got to start out like I am a total noob!

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

#149234

On 2020-01-17 12:48, T wrote:
> On 2020-01-17 12:46, Ben Bacarisse wrote:
>> T <T@invalid.invalid> writes:
>>
>>> On 2020-01-16 15:45, Ben Bacarisse wrote:
>>>> T <T@invalid.invalid> writes:
>>>>
>>>>> On 2020-01-16 12:17, Ben Bacarisse wrote:
>> <cut>
>>>>>> $ gcc -o t t.c
>>>>>> $ ./t
>> <cut>
>>>>> I am a total idiot when it comes to C.  How do
>>>>> I run this?
>>>>
>>>> I don't know.  That depends on your compiler, OS and so on and that
>>>> obviously different to mine sice whole process of compiling and running
>>>> is shown above.
>>>
>>> I have Fedora Linux at my disposal, which has
>>> a gcc c compiler.
>>
>> Then I am baffled.  I showed both the gcc command to compile the code,
>> and the command to run it.  I've removed everything else so you can see
>> them.
>>
>> <cut>
>>
> 
> Ben!  I am an idiot when it comes to C.  You
> got to start out like I am a total noob!

Okay, I looked at it from a bash standpoint instead
of a mystery language I had no clue about.  And I
feel dumb.  You were very precise!

$ cd C
$ vi t.c
$ gcc -o t t.c
$ t
[FOOp@]


Question:  why did I get
     [FOOp@]

and you got
     [FOO]
?

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

#149235

On 17/01/2020 20:54, T wrote:
> On 2020-01-17 12:48, T wrote:

>>
>> Ben!  I am an idiot when it comes to C.  You
>> got to start out like I am a total noob!
> 
> Okay, I looked at it from a bash standpoint instead
> of a mystery language I had no clue about.  And I
> feel dumb.  You were very precise!
> 
> $ cd C
> $ vi t.c
> $ gcc -o t t.c
> $ t
> [FOOp@]
> 
> 
> Question:  why did I get
>      [FOOp@]
> 
> and you got
>      [FOO]
> ?

Maybe you need a 0 terminator byte at the end of your "FOO" string.

How else will printf know how long it is? All it has is a pointer to the 
'F' character at the start.

Presumably, on one computer, there happened to be zero immediately after 
the second 'O'; while on yours, "FOO" happened to be followed by 'p' and 
'@' before it encountered a zero.

(Haven't read the thread; perhaps it's been mentioned already...)

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

#149237

On 17/01/2020 21:02, Bart wrote:
> On 17/01/2020 20:54, T wrote:
>> On 2020-01-17 12:48, T wrote:
> 
>>>
>>> Ben!  I am an idiot when it comes to C.  You
>>> got to start out like I am a total noob!
>>
>> Okay, I looked at it from a bash standpoint instead
>> of a mystery language I had no clue about.  And I
>> feel dumb.  You were very precise!
>>
>> $ cd C
>> $ vi t.c
>> $ gcc -o t t.c
>> $ t
>> [FOOp@]
>>
>>
>> Question:  why did I get
>>      [FOOp@]
>>
>> and you got
>>      [FOO]
>> ?
> 
> Maybe you need a 0 terminator byte at the end of your "FOO" string.
> 
> How else will printf know how long it is? All it has is a pointer to the 
> 'F' character at the start.
> 
> Presumably, on one computer, there happened to be zero immediately after 
> the second 'O'; while on yours, "FOO" happened to be followed by 'p' and 
> '@' before it encountered a zero.
> 
> (Haven't read the thread; perhaps it's been mentioned already...)

BTW I changed the test program to this:

---------------------------------
#include <stdio.h>

void foo(const char *s)
{
     for (int i=0; i<10; ++i)
         printf("%d ",*s++);
     puts("");

}

int main(void)
{
      char str[3] = "FOO";
      foo(str);
}
---------------------------------

This prints the 3 characters codes of F,O,O in the string, plus 7 bytes 
that follow. Results on various compilers are as follows:

bcc:         70 79 79 0 0 0 0 0 0 0
tcc:         70 79 79 80 -1 18 0 0 0 0
gcc -O0:     70 79 79 112 -14 48 0 0 0 0
gcc -O3:     70 79 79 2 0 0 0 0 0 0
lcc:         70 79 79 0 0 0 0 0 0 0
dmc:         70 79 79 0 -120 -1 24 0 25 33
clang -O0:   70 79 79 16 6 64 0 0 0 0
clang -O2:   70 79 79 0 48 -120 73 6 -19 127
msvc:        70 79 79 -29 -9 127 0 0 0 0

The 70, 79, 79 are the F, O and O codes. When those 3 happen to be 
followed by 0, then it will appear to work.

That is 4 out of 9, but the other 5 won't work. What follows after FOO 
is undefined and could be anything, although a random 0 is common.

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

#149239

On 2020-01-17 13:21, Bart wrote:
> On 17/01/2020 21:02, Bart wrote:
>> On 17/01/2020 20:54, T wrote:
>>> On 2020-01-17 12:48, T wrote:
>>
>>>>
>>>> Ben!  I am an idiot when it comes to C.  You
>>>> got to start out like I am a total noob!
>>>
>>> Okay, I looked at it from a bash standpoint instead
>>> of a mystery language I had no clue about.  And I
>>> feel dumb.  You were very precise!
>>>
>>> $ cd C
>>> $ vi t.c
>>> $ gcc -o t t.c
>>> $ t
>>> [FOOp@]
>>>
>>>
>>> Question:  why did I get
>>>      [FOOp@]
>>>
>>> and you got
>>>      [FOO]
>>> ?
>>
>> Maybe you need a 0 terminator byte at the end of your "FOO" string.
>>
>> How else will printf know how long it is? All it has is a pointer to 
>> the 'F' character at the start.
>>
>> Presumably, on one computer, there happened to be zero immediately 
>> after the second 'O'; while on yours, "FOO" happened to be followed by 
>> 'p' and '@' before it encountered a zero.
>>
>> (Haven't read the thread; perhaps it's been mentioned already...)
> 
> BTW I changed the test program to this:
> 
> ---------------------------------
> #include <stdio.h>
> 
> void foo(const char *s)
> {
>      for (int i=0; i<10; ++i)
>          printf("%d ",*s++);
>      puts("");
> 
> }
> 
> int main(void)
> {
>       char str[3] = "FOO";
>       foo(str);
> }
> ---------------------------------
> 
> This prints the 3 characters codes of F,O,O in the string, plus 7 bytes 
> that follow. Results on various compilers are as follows:
> 
> bcc:         70 79 79 0 0 0 0 0 0 0
> tcc:         70 79 79 80 -1 18 0 0 0 0
> gcc -O0:     70 79 79 112 -14 48 0 0 0 0
> gcc -O3:     70 79 79 2 0 0 0 0 0 0
> lcc:         70 79 79 0 0 0 0 0 0 0
> dmc:         70 79 79 0 -120 -1 24 0 25 33
> clang -O0:   70 79 79 16 6 64 0 0 0 0
> clang -O2:   70 79 79 0 48 -120 73 6 -19 127
> msvc:        70 79 79 -29 -9 127 0 0 0 0
> 
> The 70, 79, 79 are the F, O and O codes. When those 3 happen to be 
> followed by 0, then it will appear to work.
> 
> That is 4 out of 9, but the other 5 won't work. What follows after FOO 
> is undefined and could be anything, although a random 0 is common.
> 


Oh my gosh, I have now compiled TWO C programs.
I AM DANGEROUS!!!!

:-)

vi t2.c
$ gcc -o t2 t2.c
$ t2
70 79 79 -80 17 64 0 0 0 0

Okay, I know you guys said this clearly and directly,
but I can be thick as a stone at times: is the

      -80 17 64 0 0 0 0

an example of careening until a proper terminator
is found?

-T

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

#149241

On 2020-01-17 13:35, T wrote:
> On 2020-01-17 13:21, Bart wrote:
>> On 17/01/2020 21:02, Bart wrote:
>>> On 17/01/2020 20:54, T wrote:
>>>> On 2020-01-17 12:48, T wrote:
>>>
>>>>>
>>>>> Ben!  I am an idiot when it comes to C.  You
>>>>> got to start out like I am a total noob!
>>>>
>>>> Okay, I looked at it from a bash standpoint instead
>>>> of a mystery language I had no clue about.  And I
>>>> feel dumb.  You were very precise!
>>>>
>>>> $ cd C
>>>> $ vi t.c
>>>> $ gcc -o t t.c
>>>> $ t
>>>> [FOOp@]
>>>>
>>>>
>>>> Question:  why did I get
>>>>      [FOOp@]
>>>>
>>>> and you got
>>>>      [FOO]
>>>> ?
>>>
>>> Maybe you need a 0 terminator byte at the end of your "FOO" string.
>>>
>>> How else will printf know how long it is? All it has is a pointer to 
>>> the 'F' character at the start.
>>>
>>> Presumably, on one computer, there happened to be zero immediately 
>>> after the second 'O'; while on yours, "FOO" happened to be followed 
>>> by 'p' and '@' before it encountered a zero.
>>>
>>> (Haven't read the thread; perhaps it's been mentioned already...)
>>
>> BTW I changed the test program to this:
>>
>> ---------------------------------
>> #include <stdio.h>
>>
>> void foo(const char *s)
>> {
>>      for (int i=0; i<10; ++i)
>>          printf("%d ",*s++);
>>      puts("");
>>
>> }
>>
>> int main(void)
>> {
>>       char str[3] = "FOO";
>>       foo(str);
>> }
>> ---------------------------------
>>
>> This prints the 3 characters codes of F,O,O in the string, plus 7 
>> bytes that follow. Results on various compilers are as follows:
>>
>> bcc:         70 79 79 0 0 0 0 0 0 0
>> tcc:         70 79 79 80 -1 18 0 0 0 0
>> gcc -O0:     70 79 79 112 -14 48 0 0 0 0
>> gcc -O3:     70 79 79 2 0 0 0 0 0 0
>> lcc:         70 79 79 0 0 0 0 0 0 0
>> dmc:         70 79 79 0 -120 -1 24 0 25 33
>> clang -O0:   70 79 79 16 6 64 0 0 0 0
>> clang -O2:   70 79 79 0 48 -120 73 6 -19 127
>> msvc:        70 79 79 -29 -9 127 0 0 0 0
>>
>> The 70, 79, 79 are the F, O and O codes. When those 3 happen to be 
>> followed by 0, then it will appear to work.
>>
>> That is 4 out of 9, but the other 5 won't work. What follows after FOO 
>> is undefined and could be anything, although a random 0 is common.
>>
> 
> 
> Oh my gosh, I have now compiled TWO C programs.
> I AM DANGEROUS!!!!
> 
> :-)
> 
> vi t2.c
> $ gcc -o t2 t2.c
> $ t2
> 70 79 79 -80 17 64 0 0 0 0
> 
> Okay, I know you guys said this clearly and directly,
> but I can be thick as a stone at times: is the
> 
>       -80 17 64 0 0 0 0
> 
> an example of careening until a proper terminator
> is found?
> 
> -T
> 
> 

yes it is careening.  Sorry I am so slow.

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

#149245

W dniu piątek, 17 stycznia 2020 22:21:44 UTC+1 użytkownik Bart napisał:
> On 17/01/2020 21:02, Bart wrote:
> > On 17/01/2020 20:54, T wrote:
> >> On 2020-01-17 12:48, T wrote:
> > 
> >>>
> >>> Ben!  I am an idiot when it comes to C.  You
> >>> got to start out like I am a total noob!
> >>
> >> Okay, I looked at it from a bash standpoint instead
> >> of a mystery language I had no clue about.  And I
> >> feel dumb.  You were very precise!
> >>
> >> $ cd C
> >> $ vi t.c
> >> $ gcc -o t t.c
> >> $ t
> >> [FOOp@]
> >>
> >>
> >> Question:  why did I get
> >>      [FOOp@]
> >>
> >> and you got
> >>      [FOO]
> >> ?
> > 
> > Maybe you need a 0 terminator byte at the end of your "FOO" string.
> > 
> > How else will printf know how long it is? All it has is a pointer to the 
> > 'F' character at the start.
> > 
> > Presumably, on one computer, there happened to be zero immediately after 
> > the second 'O'; while on yours, "FOO" happened to be followed by 'p' and 
> > '@' before it encountered a zero.
> > 
> > (Haven't read the thread; perhaps it's been mentioned already...)
> 
> BTW I changed the test program to this:
> 
> ---------------------------------
> #include <stdio.h>
> 
> void foo(const char *s)
> {
>      for (int i=0; i<10; ++i)
>          printf("%d ",*s++);
>      puts("");
> 
> }
> 
> int main(void)
> {
>       char str[3] = "FOO";
>       foo(str);
> }
> ---------------------------------
> 
> This prints the 3 characters codes of F,O,O in the string, plus 7 bytes 
> that follow. Results on various compilers are as follows:
> 
> bcc:         70 79 79 0 0 0 0 0 0 0
> tcc:         70 79 79 80 -1 18 0 0 0 0
> gcc -O0:     70 79 79 112 -14 48 0 0 0 0
> gcc -O3:     70 79 79 2 0 0 0 0 0 0
> lcc:         70 79 79 0 0 0 0 0 0 0
> dmc:         70 79 79 0 -120 -1 24 0 25 33
> clang -O0:   70 79 79 16 6 64 0 0 0 0
> clang -O2:   70 79 79 0 48 -120 73 6 -19 127
> msvc:        70 79 79 -29 -9 127 0 0 0 0
> 
> The 70, 79, 79 are the F, O and O codes. When those 3 happen to be 
> followed by 0, then it will appear to work.
> 
> That is 4 out of 9, but the other 5 won't work. What follows after FOO 
> is undefined and could be anything, although a random 0 is common.

i think most probably at the end of this is next data chunk, when .data section is build things are placed one by one usually, though some maybe may be aligned at least to 4

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

#149246

W dniu sobota, 18 stycznia 2020 00:03:26 UTC+1 użytkownik fir napisał:
> W dniu piątek, 17 stycznia 2020 22:21:44 UTC+1 użytkownik Bart napisał:
> > On 17/01/2020 21:02, Bart wrote:
> > > On 17/01/2020 20:54, T wrote:
> > >> On 2020-01-17 12:48, T wrote:
> > > 
> > >>>
> > >>> Ben!  I am an idiot when it comes to C.  You
> > >>> got to start out like I am a total noob!
> > >>
> > >> Okay, I looked at it from a bash standpoint instead
> > >> of a mystery language I had no clue about.  And I
> > >> feel dumb.  You were very precise!
> > >>
> > >> $ cd C
> > >> $ vi t.c
> > >> $ gcc -o t t.c
> > >> $ t
> > >> [FOOp@]
> > >>
> > >>
> > >> Question:  why did I get
> > >>      [FOOp@]
> > >>
> > >> and you got
> > >>      [FOO]
> > >> ?
> > > 
> > > Maybe you need a 0 terminator byte at the end of your "FOO" string.
> > > 
> > > How else will printf know how long it is? All it has is a pointer to the 
> > > 'F' character at the start.
> > > 
> > > Presumably, on one computer, there happened to be zero immediately after 
> > > the second 'O'; while on yours, "FOO" happened to be followed by 'p' and 
> > > '@' before it encountered a zero.
> > > 
> > > (Haven't read the thread; perhaps it's been mentioned already...)
> > 
> > BTW I changed the test program to this:
> > 
> > ---------------------------------
> > #include <stdio.h>
> > 
> > void foo(const char *s)
> > {
> >      for (int i=0; i<10; ++i)
> >          printf("%d ",*s++);
> >      puts("");
> > 
> > }
> > 
> > int main(void)
> > {
> >       char str[3] = "FOO";
> >       foo(str);
> > }
> > ---------------------------------
> > 
> > This prints the 3 characters codes of F,O,O in the string, plus 7 bytes 
> > that follow. Results on various compilers are as follows:
> > 
> > bcc:         70 79 79 0 0 0 0 0 0 0
> > tcc:         70 79 79 80 -1 18 0 0 0 0
> > gcc -O0:     70 79 79 112 -14 48 0 0 0 0
> > gcc -O3:     70 79 79 2 0 0 0 0 0 0
> > lcc:         70 79 79 0 0 0 0 0 0 0
> > dmc:         70 79 79 0 -120 -1 24 0 25 33
> > clang -O0:   70 79 79 16 6 64 0 0 0 0
> > clang -O2:   70 79 79 0 48 -120 73 6 -19 127
> > msvc:        70 79 79 -29 -9 127 0 0 0 0
> > 
> > The 70, 79, 79 are the F, O and O codes. When those 3 happen to be 
> > followed by 0, then it will appear to work.
> > 
> > That is 4 out of 9, but the other 5 won't work. What follows after FOO 
> > is undefined and could be anything, although a random 0 is common.
> 
> i think most probably at the end of this is next data chunk, when .data section is build things are placed one by one usually, though some maybe may be aligned at least to 4

though here what is after might be just pice of stack (i didnt looked at code that its on stack) and the oryginal might be stored in .data also

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

#149252

On 2020-01-17, Bart <bc@freeuk.com> wrote:
> [...]
> ---------------------------------
> #include <stdio.h>
>
> void foo(const char *s)
> {
>      for (int i=0; i<10; ++i)
>          printf("%d ",*s++);
>      puts("");
>
> }
>
> int main(void)
> {
>       char str[3] = "FOO";
>       foo(str);
> }
> ---------------------------------
>
> This prints the 3 characters codes of F,O,O in the string, plus 7 bytes 
> that follow. Results on various compilers are as follows:
>
> bcc:         70 79 79 0 0 0 0 0 0 0
> tcc:         70 79 79 80 -1 18 0 0 0 0
> gcc -O0:     70 79 79 112 -14 48 0 0 0 0
> gcc -O3:     70 79 79 2 0 0 0 0 0 0
> lcc:         70 79 79 0 0 0 0 0 0 0
> dmc:         70 79 79 0 -120 -1 24 0 25 33
> clang -O0:   70 79 79 16 6 64 0 0 0 0
> clang -O2:   70 79 79 0 48 -120 73 6 -19 127
> msvc:        70 79 79 -29 -9 127 0 0 0 0
>
> The 70, 79, 79 are the F, O and O codes. When those 3 happen to be 
> followed by 0, then it will appear to work.
>
> That is 4 out of 9, but the other 5 won't work. What follows after FOO 
> is undefined and could be anything, although a random 0 is common.

It may also appear to work for character codes that produce no visible output.

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

#149236

T wrote:

> On 2020-01-17 12:48, T wrote:
>> On 2020-01-17 12:46, Ben Bacarisse wrote:
>>> T <T@invalid.invalid> writes:
>>>
>>>> On 2020-01-16 15:45, Ben Bacarisse wrote:
>>>>> T <T@invalid.invalid> writes:
>>>>>
>>>>>> On 2020-01-16 12:17, Ben Bacarisse wrote:
>>> <cut>
>>>>>>> $ gcc -o t t.c
>>>>>>> $ ./t
>>> <cut>
>>>>>> I am a total idiot when it comes to C.  How do
>>>>>> I run this?
>>>>>
>>>>> I don't know.  That depends on your compiler, OS and so on and that
>>>>> obviously different to mine sice whole process of compiling and
>>>>> running is shown above.
>>>>
>>>> I have Fedora Linux at my disposal, which has
>>>> a gcc c compiler.
>>>
>>> Then I am baffled.  I showed both the gcc command to compile the code,
>>> and the command to run it.  I've removed everything else so you can see
>>> them.
>>>
>>> <cut>
>>>
>> 
>> Ben!  I am an idiot when it comes to C.  You
>> got to start out like I am a total noob!
> 
> Okay, I looked at it from a bash standpoint instead
> of a mystery language I had no clue about.  And I
> feel dumb.  You were very precise!
> 
> $ cd C
> $ vi t.c
> $ gcc -o t t.c
> $ t
> [FOOp@]
> 
> 
> Question:  why did I get
>      [FOOp@]
> 
> and you got
>      [FOO]
> ?

Because, as implied by Ben's source code comment, the program given
>>>>>>> #include <stdio.h>
>>>>>>>
>>>>>>> void foo(const char *s)
>>>>>>> {
>>>>>>>     printf("[%s]\n", s);
>>>>>>> }
>>>>>>>
>>>>>>> int main(void)
>>>>>>> {
>>>>>>>      char str[3] = "FOO";
>>>>>>>      foo(str); // DANGER, WILL ROBINSON!
>>>>>>> }
invokes undefined behaviour.

It does this by passing an array of three characters (ultimately) to 
printf(), which /expects/ a C "string" as it's first argument. The array of 
three characters passed /does not/ represent a C "string", as it lacks the 
requisite nul ('\0') terminator that all C "string"s have.

In Ben's example execution, his code was fortunate enough to find a nul 
character in unallocated, uninitialized, (and thus undependable) memory 
immediately following the three character array. /His/ execution, then, 
acted as if that three character array was, indeed, a C "string", and acted 
accordingly.

In /your/ example execution, on the other hand, your code was unfortunate 
enough to /not/ encounter a nul character until somewhat after the end of 
the three character array (again, somewhere in unallocated, uninitialized, 
(and thus undependable) memory). /Your/ execution emitted an additional 
character /that was not in the original array/. /Your/ execution was 
analogous to the situation you attempt to describe to the Raku maintainers, 
and represents the likely outcome of a Raku NativeCall call to a C function 
that /expects/ a C "string".

HTH
-- 
Lew Pitcher
"In Skills, We Trust"

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

#149238

Two minor corrections

Lew Pitcher wrote:

> T wrote:
> 
>> On 2020-01-17 12:48, T wrote:
>>> On 2020-01-17 12:46, Ben Bacarisse wrote:
>>>> T <T@invalid.invalid> writes:
>>>>
>>>>> On 2020-01-16 15:45, Ben Bacarisse wrote:
>>>>>> T <T@invalid.invalid> writes:
>>>>>>
>>>>>>> On 2020-01-16 12:17, Ben Bacarisse wrote:
>>>> <cut>
>>>>>>>> $ gcc -o t t.c
>>>>>>>> $ ./t
>>>> <cut>
>>>>>>> I am a total idiot when it comes to C.  How do
>>>>>>> I run this?
>>>>>>
>>>>>> I don't know.  That depends on your compiler, OS and so on and that
>>>>>> obviously different to mine sice whole process of compiling and
>>>>>> running is shown above.
>>>>>
>>>>> I have Fedora Linux at my disposal, which has
>>>>> a gcc c compiler.
>>>>
>>>> Then I am baffled.  I showed both the gcc command to compile the code,
>>>> and the command to run it.  I've removed everything else so you can see
>>>> them.
>>>>
>>>> <cut>
>>>>
>>> 
>>> Ben!  I am an idiot when it comes to C.  You
>>> got to start out like I am a total noob!
>> 
>> Okay, I looked at it from a bash standpoint instead
>> of a mystery language I had no clue about.  And I
>> feel dumb.  You were very precise!
>> 
>> $ cd C
>> $ vi t.c
>> $ gcc -o t t.c
>> $ t
>> [FOOp@]
>> 
>> 
>> Question:  why did I get
>>      [FOOp@]
>> 
>> and you got
>>      [FOO]
>> ?
> 
> Because, as implied by Ben's source code comment, the program given
>>>>>>>> #include <stdio.h>
>>>>>>>>
>>>>>>>> void foo(const char *s)
>>>>>>>> {
>>>>>>>>     printf("[%s]\n", s);
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main(void)
>>>>>>>> {
>>>>>>>>      char str[3] = "FOO";
>>>>>>>>      foo(str); // DANGER, WILL ROBINSON!
>>>>>>>> }
> invokes undefined behaviour.
> 
> It does this by passing an array of three characters (ultimately) to
> printf(), which /expects/ a C "string" as it's first argument. The array

Correction #1: in this case, the critical point is that, here, printf() 
expects a C "string" as it's second argument (as well as the first argument, 
which is the given format string "[%s]\n").

> of three characters passed /does not/ represent a C "string", as it lacks
> the requisite nul ('\0') terminator that all C "string"s have.
> 
> In Ben's example execution, his code was fortunate enough to find a nul
> character in unallocated, uninitialized, (and thus undependable) memory
> immediately following the three character array. /His/ execution, then,
> acted as if that three character array was, indeed, a C "string", and
> acted accordingly.
> 
> In /your/ example execution, on the other hand, your code was unfortunate
> enough to /not/ encounter a nul character until somewhat after the end of
> the three character array (again, somewhere in unallocated, uninitialized,
> (and thus undependable) memory). /Your/ execution emitted an additional
> character 

Correction #2: your execution emitted an additional two characters that were 
not in the original array.

> /that was not in the original array/. /Your/ execution was
> analogous to the situation you attempt to describe to the Raku
> maintainers, and represents the likely outcome of a Raku NativeCall call
> to a C function that /expects/ a C "string".
> 
> HTH


-- 
Lew Pitcher
Gotta stop skimming code.

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

#149240

On 2020-01-17 13:23, Lew Pitcher wrote:
> Two minor corrections
> 
> Lew Pitcher wrote:
> 
>> T wrote:
>>
>>> On 2020-01-17 12:48, T wrote:
>>>> On 2020-01-17 12:46, Ben Bacarisse wrote:
>>>>> T <T@invalid.invalid> writes:
>>>>>
>>>>>> On 2020-01-16 15:45, Ben Bacarisse wrote:
>>>>>>> T <T@invalid.invalid> writes:
>>>>>>>
>>>>>>>> On 2020-01-16 12:17, Ben Bacarisse wrote:
>>>>> <cut>
>>>>>>>>> $ gcc -o t t.c
>>>>>>>>> $ ./t
>>>>> <cut>
>>>>>>>> I am a total idiot when it comes to C.  How do
>>>>>>>> I run this?
>>>>>>>
>>>>>>> I don't know.  That depends on your compiler, OS and so on and that
>>>>>>> obviously different to mine sice whole process of compiling and
>>>>>>> running is shown above.
>>>>>>
>>>>>> I have Fedora Linux at my disposal, which has
>>>>>> a gcc c compiler.
>>>>>
>>>>> Then I am baffled.  I showed both the gcc command to compile the code,
>>>>> and the command to run it.  I've removed everything else so you can see
>>>>> them.
>>>>>
>>>>> <cut>
>>>>>
>>>>
>>>> Ben!  I am an idiot when it comes to C.  You
>>>> got to start out like I am a total noob!
>>>
>>> Okay, I looked at it from a bash standpoint instead
>>> of a mystery language I had no clue about.  And I
>>> feel dumb.  You were very precise!
>>>
>>> $ cd C
>>> $ vi t.c
>>> $ gcc -o t t.c
>>> $ t
>>> [FOOp@]
>>>
>>>
>>> Question:  why did I get
>>>       [FOOp@]
>>>
>>> and you got
>>>       [FOO]
>>> ?
>>
>> Because, as implied by Ben's source code comment, the program given
>>>>>>>>> #include <stdio.h>
>>>>>>>>>
>>>>>>>>> void foo(const char *s)
>>>>>>>>> {
>>>>>>>>>      printf("[%s]\n", s);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main(void)
>>>>>>>>> {
>>>>>>>>>       char str[3] = "FOO";
>>>>>>>>>       foo(str); // DANGER, WILL ROBINSON!
>>>>>>>>> }
>> invokes undefined behaviour.
>>
>> It does this by passing an array of three characters (ultimately) to
>> printf(), which /expects/ a C "string" as it's first argument. The array
> 
> Correction #1: in this case, the critical point is that, here, printf()
> expects a C "string" as it's second argument (as well as the first argument,
> which is the given format string "[%s]\n").
> 
>> of three characters passed /does not/ represent a C "string", as it lacks
>> the requisite nul ('\0') terminator that all C "string"s have.
>>
>> In Ben's example execution, his code was fortunate enough to find a nul
>> character in unallocated, uninitialized, (and thus undependable) memory
>> immediately following the three character array. /His/ execution, then,
>> acted as if that three character array was, indeed, a C "string", and
>> acted accordingly.
>>
>> In /your/ example execution, on the other hand, your code was unfortunate
>> enough to /not/ encounter a nul character until somewhat after the end of
>> the three character array (again, somewhere in unallocated, uninitialized,
>> (and thus undependable) memory). /Your/ execution emitted an additional
>> character
> 
> Correction #2: your execution emitted an additional two characters that were
> not in the original array.
> 
>> /that was not in the original array/. /Your/ execution was
>> analogous to the situation you attempt to describe to the Raku
>> maintainers, and represents the likely outcome of a Raku NativeCall call
>> to a C function that /expects/ a C "string".
>>
>> HTH
> 
> 

Got it!

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

#149303

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> Two minor corrections
>
> Lew Pitcher wrote:
>
>> T wrote:
>>
>>> On 2020-01-17 12:48, T wrote:
>>>
>>>> On 2020-01-17 12:46, Ben Bacarisse wrote:
>>>>
>>>>> T <T@invalid.invalid> writes:
>>>>>
>>>>>> On 2020-01-16 15:45, Ben Bacarisse wrote:
>>>>>>
>>>>>>> T <T@invalid.invalid> writes:
>>>>>>>
>>>>>>>> On 2020-01-16 12:17, Ben Bacarisse wrote:
>>>>>
>>>>> <cut>
>>>>>
>>>>>>>>> $ gcc -o t t.c
>>>>>>>>> $ ./t
>>>>>
>>>>> <cut>
>>>>>
>>>>>>>> I am a total idiot when it comes to C.  How do
>>>>>>>> I run this?
>>>>>>>
>>>>>>> I don't know.  That depends on your compiler, OS and so on and that
>>>>>>> obviously different to mine sice whole process of compiling and
>>>>>>> running is shown above.
>>>>>>
>>>>>> I have Fedora Linux at my disposal, which has
>>>>>> a gcc c compiler.
>>>>>
>>>>> Then I am baffled.  I showed both the gcc command to compile the code,
>>>>> and the command to run it.  I've removed everything else so you can see
>>>>> them.
>>>>>
>>>>> <cut>
>>>>
>>>> Ben!  I am an idiot when it comes to C.  You
>>>> got to start out like I am a total noob!
>>>
>>> Okay, I looked at it from a bash standpoint instead
>>> of a mystery language I had no clue about.  And I
>>> feel dumb.  You were very precise!
>>>
>>> $ cd C
>>> $ vi t.c
>>> $ gcc -o t t.c
>>> $ t
>>> [FOOp@]
>>>
>>>
>>> Question:  why did I get
>>>      [FOOp@]
>>>
>>> and you got
>>>      [FOO]
>>> ?
>>
>> Because, as implied by Ben's source code comment, the program given
>>
>>>>>>>>> #include <stdio.h>
>>>>>>>>>
>>>>>>>>> void foo(const char *s)
>>>>>>>>> {
>>>>>>>>>     printf("[%s]\n", s);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main(void)
>>>>>>>>> {
>>>>>>>>>      char str[3] = "FOO";
>>>>>>>>>      foo(str); // DANGER, WILL ROBINSON!
>>>>>>>>> }
>>
>> invokes undefined behaviour.
>>
>> It does this by passing an array of three characters (ultimately) to
>> printf(), which /expects/ a C "string" as it's first argument.  The array
>
> Correction #1: in this case, the critical point is that, here, printf()
> expects a C "string" as it's second argument (as well as the first argument,
> which is the given format string "[%s]\n").

Technically, that isn't right.  A %s conversion specifier requires
as its argument a pointer to the first element of an array of
character type, not a pointer to a string.  It is true in this
particular case that the array must have a null character in it to
avoid undefined behavior, but the argument description says "pointer
to array of character type", and does not mention "string".

(Also:  the possessive of "it" is "its", with no apostrophe.  The
word "it's", with an apostrophe, is a contraction of "it is".)

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

#149318

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
[...]
>> Correction #1: in this case, the critical point is that, here, printf()
>> expects a C "string" as it's second argument (as well as the first argument,
>> which is the given format string "[%s]\n").
> 
> Technically, that isn't right.  A %s conversion specifier requires
> as its argument a pointer to the first element of an array of
> character type, not a pointer to a string.  It is true in this
> particular case that the array must have a null character in it to
> avoid undefined behavior, but the argument description says "pointer
> to array of character type", and does not mention "string".
>
> (Also:  the possessive of "it" is "its", with no apostrophe.  The
> word "it's", with an apostrophe, is a contraction of "it is".)

I believe the reason it's described that way is that %s with a field
width can require a pointer that isn't necessarily a pointer to a
string.  For example, this is well defined:

    char not_a_string[3] = "foo";
    printf("%.3s\n", not_a_string);

The standard *could* have equivalently stated that a pointer to a string
is required when the format contains a "%s" directive, but that would
have made it overly wordy with no clear benefit.  A pointer to a string
*is* required for a "%s" directive, but the standard says so only
indirectly.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#149217

On Thursday, 16 January 2020 22:14:42 UTC, T  wrote:
> On 2020-01-16 12:17, Ben Bacarisse wrote:
> > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> > 
> >> T <T@invalid.invalid> writes:
> >>
> >>> On 2020-01-16 05:31, Ben Bacarisse wrote:
> >>>> You have not yet achieved your goal!  Can you submit a patch to the
> >>>> documentation?
> >>>
> >>> I got shot down by the first responder before I even
> >>> got that far.  If the example works, then there is
> >>> not bug.  The correspondence was with him
> >>
> >> Then you need to concoct a simple example that does not work.
> > 
> > That's not always easy.  I may be very hard indeed.  Here's a C example:
> > 
> > $ cat t.c
> > #include <stdio.h>
> > 
> > void foo(const char *s)
> > {
> >       printf("[%s]\n", s);
> > }
> > 
> > int main(void)
> > {
> >       char str[3] = "FOO";
> >       foo(str); // DANGER, WILL ROBINSON!
> > }
> > $ gcc -o t t.c
> > $ ./t
> > [FOO]
> > 
> > All must be well because it works!  It's even harder when the C function
> > is called from a high-level language where there is far less chance to
> > control data layout etc.
> > 
> > People should accept a simple, well-argued claim that something is
> > wrong.
> > 
> 
> Hi Ben,
> 
> I am a total idiot when it comes to C.  How do
> I run this?
> 
> Does char str[3] = "FOO"; mean there cells (bytes?)
> or 4 [0..3]?
> 
It means three "cells". The index goes from 0-2 inclusive.

Normally C strings are nul-terminated, however there is a little quirk in
the language which means that in this case the nul is left off, because 
you have specified exactly three chars in both buffer and string literal.

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

#149227

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Thursday, 16 January 2020 22:14:42 UTC, T  wrote:
[...]
>> Does char str[3] = "FOO"; mean there cells (bytes?)
>> or 4 [0..3]?
>> 
> It means three "cells". The index goes from 0-2 inclusive.
>
> Normally C strings are nul-terminated, however there is a little quirk in
> the language which means that in this case the nul is left off, because 
> you have specified exactly three chars in both buffer and string literal.

Mostly correct, but C strings are always nul-terminated, by definition.
In
    char str[3] = "FOO";
str does not contain a C string.

I'm assuming the phrase "C string" is enough to convey that I'm
referring to the technical term as defined in the C standard.

A trivial digression: Strictly speaking, the string literal "FOO"
specifies an anonymous array object of 4 characters, {'F', 'O', 'O',
'\0'}.  Only the first 3 bytes of that object are used to initialize
str.  N1570 6.7.9p14:

    An array of character type may be initialized by a character
    string literal or UTF−8 string literal, optionally enclosed
    in braces. Successive bytes of the string literal (including
    the terminating null character if there is room or if the array
    is of unknown size) initialize the elements of the array.

It's likely that the 4-character terminated array won't actually be
generated or stored anywhere.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#149230

On 2020-01-17 09:52, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On Thursday, 16 January 2020 22:14:42 UTC, T  wrote:
> [...]
>>> Does char str[3] = "FOO"; mean there cells (bytes?)
>>> or 4 [0..3]?
>>>
>> It means three "cells". The index goes from 0-2 inclusive.
>>
>> Normally C strings are nul-terminated, however there is a little quirk in
>> the language which means that in this case the nul is left off, because
>> you have specified exactly three chars in both buffer and string literal.
> 
> Mostly correct, but C strings are always nul-terminated, by definition.
> In
>      char str[3] = "FOO";
> str does not contain a C string.
> 
> I'm assuming the phrase "C string" is enough to convey that I'm
> referring to the technical term as defined in the C standard.
> 
> A trivial digression: Strictly speaking, the string literal "FOO"
> specifies an anonymous array object of 4 characters, {'F', 'O', 'O',
> '\0'}.  Only the first 3 bytes of that object are used to initialize
> str.  N1570 6.7.9p14:
> 
>      An array of character type may be initialized by a character
>      string literal or UTF−8 string literal, optionally enclosed
>      in braces. Successive bytes of the string literal (including
>      the terminating null character if there is room or if the array
>      is of unknown size) initialize the elements of the array.
> 
> It's likely that the 4-character terminated array won't actually be
> generated or stored anywhere.
> 

I am saving that one!

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

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

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

csiph-web