Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #149088 > unrolled thread
| Started by | T <T@invalid.invalid> |
|---|---|
| First post | 2020-01-14 09:22 -0800 |
| Last post | 2020-01-22 18:44 +0100 |
| Articles | 14 on this page of 114 — 22 participants |
Back to article view | Back to comp.lang.c
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 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-01-16 18:21 +0000 |
| Message-ID | <87tv4vclf1.fsf@bsb.me.uk> |
| In reply to | #149193 |
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. I don't think you need permission from the mailing list to submit a patch. That would be odd. > If the example works, then there is > not bug. The correspondence was with him The example in the documentation is not complete so you can't tell if there is a bug in the code. There is definitely a bug in the documentation because it should not use an example that replies on some rather unlikely behaviour from the called C program. The example presented to you in the mailing list discussion is out-and-out wrong. It included the called C function so we can tell for sure. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-16 10:50 -0800 |
| Message-ID | <qvqbaj$b2h$1@dont-email.me> |
| In reply to | #149197 |
On 2020-01-16 10:21, Ben Bacarisse wrote: > 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. > > I don't think you need permission from the mailing list to submit a > patch. That would be odd. The conversation on the mailing list was with the first responder on bug reporter. If I can't get it past him on the mailing list, there is zero chance I would get it past him on the bug reporter. It was only unusual in that I was able to speak to him before hand. >> If the example works, then there is >> not bug. The correspondence was with him > > The example in the documentation is not complete so you can't tell if > there is a bug in the code. There is definitely a bug in the > documentation because it should not use an example that replies on some > rather unlikely behaviour from the called C program. 1+ > > The example presented to you in the mailing list discussion is > out-and-out wrong. It included the called C function so we can tell for > sure. I make so many mistakes that I get lost after a while. Which one were you referring to?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-01-16 20:50 +0000 |
| Message-ID | <87imlbcehl.fsf@bsb.me.uk> |
| In reply to | #149198 |
T <T@invalid.invalid> writes:
> On 2020-01-16 10:21, Ben Bacarisse wrote:
>> 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.
>>
>> I don't think you need permission from the mailing list to submit a
>> patch. That would be odd.
>
> The conversation on the mailing list was with the
> first responder on bug reporter. If I can't get
> it past him on the mailing list, there is zero
> chance I would get it past him on the bug reporter.
>
> It was only unusual in that I was able to speak to
> him before hand.
And he encouraged you to report it.
I think personalities have got in the way of making a small but useful
contribution to the Raku documentation.
<cut>
>> The example presented to you in the mailing list discussion is
>> out-and-out wrong. It included the called C function so we can tell for
>> sure.
>
> I make so many mistakes that I get lost after a while.
> Which one were you referring to?
It's the example presented /to/ you, not one you presented:
| ------ >8 ---------- const-char.c ----------------------
| #include <stdio.h>
|
| void set_foo ( const char *foo) {
| printf("%s", foo);
| }
| ----------------- 8< -------------------------------------
|
| And this Raku script that uses it
|
| ------ >8 --------------- null-terminated-or-not.p6 ------
| use NativeCall;
|
| my $string = "FOO";
| my $array = CArray[uint8].new($string.encode.list);
| sub set_foo(CArray[uint8]) is native('const-char') { * }
| set_foo( $array );
| ----------------- 8< --------------------------------------
Here, the argument to the C function /must/ point to a null-terminated
array of bytes.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-16 14:17 -0800 |
| Message-ID | <qvqndm$3kq$3@dont-email.me> |
| In reply to | #149203 |
On 2020-01-16 12:50, Ben Bacarisse wrote:
> T <T@invalid.invalid> writes:
>
>> On 2020-01-16 10:21, Ben Bacarisse wrote:
>>> 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.
>>>
>>> I don't think you need permission from the mailing list to submit a
>>> patch. That would be odd.
>>
>> The conversation on the mailing list was with the
>> first responder on bug reporter. If I can't get
>> it past him on the mailing list, there is zero
>> chance I would get it past him on the bug reporter.
>>
>> It was only unusual in that I was able to speak to
>> him before hand.
>
> And he encouraged you to report it.
He always does. That why I ran it by him first. He
shot it down.
>
> I think personalities have got in the way of making a small but useful
> contribution to the Raku documentation.
JJ and I actually get along pretty well, considering.
He is a pretty nice guy.
>
> <cut>
>>> The example presented to you in the mailing list discussion is
>>> out-and-out wrong. It included the called C function so we can tell for
>>> sure.
>>
>> I make so many mistakes that I get lost after a while.
>> Which one were you referring to?
>
> It's the example presented /to/ you, not one you presented:
>
> | ------ >8 ---------- const-char.c ----------------------
> | #include <stdio.h>
> |
> | void set_foo ( const char *foo) {
> | printf("%s", foo);
> | }
> | ----------------- 8< -------------------------------------
> |
> | And this Raku script that uses it
> |
> | ------ >8 --------------- null-terminated-or-not.p6 ------
> | use NativeCall;
> |
> | my $string = "FOO";
> | my $array = CArray[uint8].new($string.encode.list);
> | sub set_foo(CArray[uint8]) is native('const-char') { * }
> | set_foo( $array );
> | ----------------- 8< --------------------------------------
>
> Here, the argument to the C function /must/ point to a null-terminated
> array of bytes.
>
now sure who is do what to whom.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-15 09:59 -0800 |
| Message-ID | <87r200ios3.fsf@nosuchdomain.example.com> |
| In reply to | #149088 |
T <T@invalid.invalid> writes:
> Had this conversatio with someone over on the
> Raku mailing list:
>
>>> By the way, "C String" REQUIRES a nul at the end:
>>> an error in the NativeCall documentation.
>
>> No, it does not. And even if it did, it should better go to the C,
>> not Raku, documentation
>
> Would someone correct me if a C String actually does
> not require a nul to terminate itself?
>
> If I am correct, would someone give me the chapter and
> verse in the ISO that states this. (The guy I am
> conversing with will ot take a third party definition.)
Can you provide a link to the discussion? There are several Raku
mailing lists.
--
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]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-15 10:15 -0800 |
| Message-ID | <qvnkru$tu6$1@dont-email.me> |
| In reply to | #149088 |
On 2020-01-14 09:22, T wrote: > Hi All, > > Had this conversatio with someone over on the > Raku mailing list: > >>> By the way, "C String" REQUIRES a nul at the end: >>> an error in the NativeCall documentation. > >> No, it does not. And even if it did, it should better go to the C, not >> Raku, documentation > > Would someone correct me if a C String actually does > not require a nul to terminate itself? > > If I am correct, would someone give me the chapter and > verse in the ISO that states this. (The guy I am > conversing with will ot take a third party definition.) > > > Wow! Thank you all!!!
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-18 21:42 -0800 |
| Message-ID | <r00q7t$t2l$1@dont-email.me> |
| In reply to | #149088 |
On 2020-01-14 09:22, T wrote: > Hi All, > > Had this conversatio with someone over on the > Raku mailing list: > >>> By the way, "C String" REQUIRES a nul at the end: >>> an error in the NativeCall documentation. > >> No, it does not. And even if it did, it should better go to the C, not >> Raku, documentation > > Would someone correct me if a C String actually does > not require a nul to terminate itself? > > If I am correct, would someone give me the chapter and > verse in the ISO that states this. (The guy I am > conversing with will ot take a third party definition.) > > > Follow up: Joy! https://www.mail-archive.com/perl6-users@perl.org/msg07805.html JJ finally relented. Thank you all for the help! -T
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-19 22:13 -0800 |
| Message-ID | <r03gdo$f7g$1@dont-email.me> |
| In reply to | #149259 |
n 2020-01-18 21:42, T wrote:
> Follow up:
>
> Joy!
>
> https://www.mail-archive.com/perl6-users@perl.org/msg07805.html
>
> JJ finally relented.
>
> Thank you all for the help!
>
> -T
Hi All,
Once JJ agreed this was a bug and it got posted,
the developers ran with it and even created a new
class to handle the problem.
https://github.com/Raku/doc/pull/3171#issuecomment-575991403
# class CArray
multi new (Str $data , :$encoding = 'utf8') {
self.new($data.encode($encoding).list, 0)
}
Wow! Better than I had even hoped for!
-T
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-21 19:49 +0100 |
| Message-ID | <r07h3g$lad$1@news.albasani.net> |
| In reply to | #149088 |
I think it's ridiculous to fight over lexical definitions. If you have a C-typical string with a zero-terminator, use the proper functions for it. If you have something different, use other functions. Simply don't care what the language standard says.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2020-01-21 15:33 -0800 |
| Message-ID | <b6ef5c2e-7e90-47d0-bc0e-ff321c0983b6@googlegroups.com> |
| In reply to | #149088 |
On Tuesday, January 14, 2020 at 11:22:24 AM UTC-6, T wrote: > Hi All, > > Had this conversatio with someone over on the > Raku mailing list: > > >> By the way, "C String" REQUIRES a nul at the end: > >> an error in the NativeCall documentation. > > > No, it does not. And even if it did, it should better go to the C, not Raku, documentation > > Would someone correct me if a C String actually does > not require a nul to terminate itself? > > If I am correct, would someone give me the chapter and > verse in the ISO that states this. (The guy I am > conversing with will ot take a third party definition.) C 2011 Online Draft (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf), 7.1.1, paragraph 1: > A string is a contiguous sequence of characters TERMINATED BY AND INCLUDING the > first null character. The term multibyte string is sometimes used instead to emphasize > special processing given to multibyte characters contained in the string or to avoid > confusion with a wide string. A pointer to a string is a pointer to its initial (lowest > addressed) character. The length of a string is the number of bytes preceding the null > character and the value of a string is the sequence of the values of the contained > characters, in order. Emphasis added. In order to be considered a *string* in C, a sequence of characters *must* be terminated by a nul character.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-21 23:19 -0800 |
| Message-ID | <874kwo7yby.fsf@nosuchdomain.example.com> |
| In reply to | #149332 |
John Bode <jfbode1029@gmail.com> writes:
> On Tuesday, January 14, 2020 at 11:22:24 AM UTC-6, T wrote:
>> Had this conversatio with someone over on the
>> Raku mailing list:
>>
>> >> By the way, "C String" REQUIRES a nul at the end:
>> >> an error in the NativeCall documentation.
>>
>> > No, it does not. And even if it did, it should better go to the C,
>> > not Raku, documentation
>>
>> Would someone correct me if a C String actually does
>> not require a nul to terminate itself?
>>
>> If I am correct, would someone give me the chapter and
>> verse in the ISO that states this. (The guy I am
>> conversing with will ot take a third party definition.)
>
> C 2011 Online Draft (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf),
> 7.1.1, paragraph 1:
>
>> A string is a contiguous sequence of characters TERMINATED BY AND INCLUDING the
>> first null character.
[...]
> Emphasis added. In order to be considered a *string* in C, a sequence
> of characters *must* be terminated by a nul character.
That definition has been cited several times in the week since this
thread started.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-22 08:39 +0100 |
| Message-ID | <r08u6t$emb$1@news.albasani.net> |
| In reply to | #149332 |
> C 2011 Online Draft (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf), > 7.1.1, paragraph 1: >> A string is a contiguous sequence of characters TERMINATED BY AND INCLUDING the >> first null character. The term multibyte string is sometimes used instead to emphasize >> special processing given to multibyte characters contained in the string or to avoid >> confusion with a wide string. A pointer to a string is a pointer to its initial (lowest >> addressed) character. The length of a string is the number of bytes preceding the null >> character and the value of a string is the sequence of the values of the contained >> characters, in order. > Emphasis added. In order to be considered a *string* in C, a sequence of characters > *must* be terminated by a nul character. Only idiots here.
[toc] | [prev] | [next] | [standalone]
| From | chad <cdalten@gmail.com> |
|---|---|
| Date | 2020-01-22 06:59 -0800 |
| Message-ID | <ea36406c-d627-47fc-8cef-fb9a955f4b2f@googlegroups.com> |
| In reply to | #149337 |
On Tuesday, January 21, 2020 at 11:39:17 PM UTC-8, Bonita Montero wrote: > > C 2011 Online Draft (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf), > > 7.1.1, paragraph 1: > >> A string is a contiguous sequence of characters TERMINATED BY AND INCLUDING the > >> first null character. The term multibyte string is sometimes used instead to emphasize > >> special processing given to multibyte characters contained in the string or to avoid > >> confusion with a wide string. A pointer to a string is a pointer to its initial (lowest > >> addressed) character. The length of a string is the number of bytes preceding the null > >> character and the value of a string is the sequence of the values of the contained > >> characters, in order. > > Emphasis added. In order to be considered a *string* in C, a sequence of characters > > *must* be terminated by a nul character. > > Only idiots here. Versus dealing with the idiots in Marketing at a job? Or dealing with idiot bosses who set unrealistic engineering deadlines?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-22 18:44 +0100 |
| Message-ID | <r0a1lb$ksf$1@news.albasani.net> |
| In reply to | #149346 |
>>> C 2011 Online Draft (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf), >>> 7.1.1, paragraph 1: >>>> A string is a contiguous sequence of characters TERMINATED BY AND INCLUDING the >>>> first null character. The term multibyte string is sometimes used instead to emphasize >>>> special processing given to multibyte characters contained in the string or to avoid >>>> confusion with a wide string. A pointer to a string is a pointer to its initial (lowest >>>> addressed) character. The length of a string is the number of bytes preceding the null >>>> character and the value of a string is the sequence of the values of the contained >>>> characters, in order. >>> Emphasis added. In order to be considered a *string* in C, a sequence of characters >>> *must* be terminated by a nul character. >> Only idiots here. > Versus dealing with the idiots in Marketing at a job? Or dealing with idiot bosses who set unrealistic engineering deadlines? Explaining truisms is superfluous.
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.c
csiph-web