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 | 20 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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-01-15 12:55 -0800 |
| Message-ID | <d453868b-376a-41a8-a60d-cc70284c19d8@googlegroups.com> |
| In reply to | #149157 |
On Wednesday, January 15, 2020 at 4:49:18 PM UTC-3, Guillaume wrote: > Le 15/01/2020 à 13:55, Thiago Adams a écrit : > > On Tuesday, January 14, 2020 at 8:03:46 PM UTC-3, James Kuyper wrote: > > I used to have a typedef for string. But now I think it > > is a bad idea because it is inconsistent. > > > > One inconsistency is caused by const. > > Yes, this is a common pitfall, and the reason why some guidelines > strongly advise against defining pointer types (with typedef.) > > https://wiki.sei.cmu.edu/confluence/display/c/DCL05-C.+Use+typedefs+of+non-pointer+types+only > > "Hiding" that some type is actually a pointer is a bad idea IMO - not > just for the "const" pitfall. One alternative is to define the type string as char and define some extra semantics: string * p;//ok string s; s = 'a'; //error string with size 1 can be only null s = '\0'; //ok string s[1]; s[1] = 'a'; //error string with size 1 can be only null s[0] = '\0'; //ok string s[6]; //ok char* p = s; //ok p[2] = 'a'; //ok const string* s = "test"; //ok I guess the benefices are too small. Microsoft code use to have a prefix "psz" so the information is together with the variable.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-14 21:31 -0800 |
| Message-ID | <874kwxjnfd.fsf@nosuchdomain.example.com> |
| In reply to | #149101 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> I suspect there's some true statement behind your statement that
>> "C doesn't actually have strings", but I honestly don't know what
>> it is. Can you clarify?
>
> The spec separates the definition of the language itself (everything
> before chapter 7) from the standard library (chapter 7). Unless I
> missed it, chapters 1-6 only mention strings in the context of string
> literals. The language (as distinguished from the library) has no
> builtin string data type, no builtin string operators such as
> concatenation or taking a substring, etc. The only place I know of that
> the language itself supports null-terminated strings is by adding a null
> to a string literal when initializing a pointer or a long-enough array.
> In that sense, strings are in the library but not the language.
The term "string" is defined in section 7 because nothing in the
language depends on it (note that the value of a string literal isn't a
string if it has an embedded \0), but the definition still applies, and
programs can still contain strings. In this program:
int main(void) {
char s[] = {'f', 'o', 'o', '\0'};
}
the object s contains a *string* even though it doesn't use the standard
library. More realistically, a program could pass the (decayed) value
of s to a function outside the standard library.
--
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 09:28 -0800 |
| Message-ID | <qvni4g$6q3$1@dont-email.me> |
| In reply to | #149096 |
On 2020-01-14 11:36, Joe Pfeiffer wrote: > C draft standard ISO/IEC 9899:201x Do you have a link to the current one that you quoted me from?
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-15 09:38 -0800 |
| Message-ID | <qvnin0$e9v$2@dont-email.me> |
| In reply to | #149137 |
On 2020-01-15 09:28, T wrote: > On 2020-01-14 11:36, Joe Pfeiffer wrote: >> C draft standard ISO/IEC 9899:201x > > Do you have a link to the current one that you > quoted me from? Would this be it? http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-01-15 10:50 -0700 |
| Message-ID | <1b7e1stxqq.fsf@pfeifferfamily.net> |
| In reply to | #149141 |
T <T@invalid.invalid> writes: > On 2020-01-15 09:28, T wrote: >> On 2020-01-14 11:36, Joe Pfeiffer wrote: >>> C draft standard ISO/IEC 9899:201x >> >> Do you have a link to the current one that you >> quoted me from? > > Would this be it? > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf What does that document say?
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-15 10:17 -0800 |
| Message-ID | <qvnkv4$tu6$2@dont-email.me> |
| In reply to | #149143 |
On 2020-01-15 09:50, Joe Pfeiffer wrote: > T <T@invalid.invalid> writes: > >> On 2020-01-15 09:28, T wrote: >>> On 2020-01-14 11:36, Joe Pfeiffer wrote: >>>> C draft standard ISO/IEC 9899:201x >>> >>> Do you have a link to the current one that you >>> quoted me from? >> >> Would this be it? >> >> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf > > What does that document say? > I did a screwed up search, but then corrected my typo. I now keep a copy of that PDF in my Raku documentation library so I can refer to it when interfacing to Win API calls.
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-15 09:53 -0800 |
| Message-ID | <qvnjj1$kld$2@dont-email.me> |
| In reply to | #149141 |
On 2020-01-15 09:38, T wrote: > On 2020-01-15 09:28, T wrote: >> On 2020-01-14 11:36, Joe Pfeiffer wrote: >>> C draft standard ISO/IEC 9899:201x >> >> Do you have a link to the current one that you >> quoted me from? > > Would this be it? > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf Found everything you guys have quoted. Thank you!
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-01-14 21:43 -0500 |
| Message-ID | <I%uTF.2638$8h.478@fx26.iad> |
| In reply to | #149088 |
On 1/14/20 12:22 PM, 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.) > > > 7.1.1p1 A string is a contiguous sequence of characters terminated by and including the first null character.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-01-14 22:52 -0800 |
| Message-ID | <qvmcro$1emh$1@gioia.aioe.org> |
| In reply to | #149088 |
On 1/14/2020 9:22 AM, 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.) > > > The bytes: [String_0\0String_1\0] Can be used with std C functions expecting nul. String_0 is easy, we parse up to the first null. String_1 is this first null plus one to the next... should work fine.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-01-14 22:54 -0800 |
| Message-ID | <qvmcvn$1emh$2@gioia.aioe.org> |
| In reply to | #149109 |
On 1/14/2020 10:52 PM, Chris M. Thomasson wrote: > On 1/14/2020 9:22 AM, 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.) >> >> >> > > > The bytes: [String_0\0String_1\0] To clarify, this should be 18 bytes. > > Can be used with std C functions expecting nul. String_0 is easy, we > parse up to the first null. String_1 is this first null plus one to the > next... > > should work fine. > >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-15 02:00 -0800 |
| Message-ID | <87v9pdhwet.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?
To be clear, a C string doesn't "require" a terminating null
character in the sense that it's a diagnosable error if it's missing.
Rather if a character sequence has no terminating null character,
it is by definition not a string. It might still be a valid
character sequence.
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2020-01-15 10:47 +0000 |
| Message-ID | <qvmqkq$ur3$1@news.xmission.com> |
| In reply to | #149116 |
In article <87v9pdhwet.fsf@nosuchdomain.example.com>, ... >To be clear, a C string doesn't "require" a terminating null >character in the sense that it's a diagnosable error if it's missing. >Rather if a character sequence has no terminating null character, >it is by definition not a string. It might still be a valid >character sequence. Note that, as a practical matter, it is extremely unlikely that there will not be a "terminating null character" somewhere. I.e. somewhere in memory, there will be a null character, so, by that, all character sequences are null terminated strings. Emphasis on "somewhere". I say "extremely unlikely" because it is, theoretically, possible that there is no null character anywhere in the machine's memory. But unlikely... -- (Cruz certainly has an odd face) ... it looks like someone sewed pieces of a waterlogged Reagan mask together at gunpoint ... http://www.rollingstone.com/politics/news/how-america-made-donald-trump-unstoppable-20160224
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-01-15 03:02 -0800 |
| Message-ID | <62d7a148-f0a6-4f75-9511-a69224162054@googlegroups.com> |
| In reply to | #149117 |
On Wednesday, 15 January 2020 10:48:02 UTC, Kenny McCormack wrote: > In article <87v9pdhwet.fsf@nosuchdomain.example.com>, > ... > >To be clear, a C string doesn't "require" a terminating null > >character in the sense that it's a diagnosable error if it's missing. > >Rather if a character sequence has no terminating null character, > >it is by definition not a string. It might still be a valid > >character sequence. > > Note that, as a practical matter, it is extremely unlikely that there will > not be a "terminating null character" somewhere. I.e. somewhere in memory, > there will be a null character, so, by that, all character sequences are > null terminated strings. Emphasis on "somewhere". > > I say "extremely unlikely" because it is, theoretically, possible that > there is no null character anywhere in the machine's memory. But > unlikely... > The program might segfault before it hits the null. Still rather unlikely because bytes with value zero are extremely common. But less unlikely than there being no null at all in memory.
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-15 10:19 -0800 |
| Message-ID | <qvnl2n$tu6$3@dont-email.me> |
| In reply to | #149116 |
On 2020-01-15 02:00, Keith Thompson wrote: Hi Keith, I accidentally hit the wrong button and lost your last letter. I now have everything I need. Do you still want the link to the discussion? -T
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-15 11:33 -0800 |
| Message-ID | <87eew0ikfe.fsf@nosuchdomain.example.com> |
| In reply to | #149149 |
T <T@invalid.invalid> writes:
> On 2020-01-15 02:00, Keith Thompson wrote:
> I accidentally hit the wrong button and
> lost your last letter.
>
> I now have everything I need. Do you still
> want the link to the discussion?
Yes. (Wouldn't it have been easier to post the link, or even email
it to me, rather than asking whether I still want it?)
--
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 12:03 -0800 |
| Message-ID | <qvnr62$5ln$1@dont-email.me> |
| In reply to | #149156 |
On 2020-01-15 11:33, Keith Thompson wrote:
> T <T@invalid.invalid> writes:
>> On 2020-01-15 02:00, Keith Thompson wrote:
>> I accidentally hit the wrong button and
>> lost your last letter.
>>
>> I now have everything I need. Do you still
>> want the link to the discussion?
>
> Yes. (Wouldn't it have been easier to post the link, or even email
> it to me, rather than asking whether I still want it?)
>
Actually, no. I had to do a bunch of detective work.
This subject appears in two threads:
NativeCall Doc booboo
https://www.nntp.perl.org/group/perl.perl6.users/2019/12/msg7586.html
My favorite response was:
It will not be corrected because it's not a
documentation error. Also, using strings in the way
your other (native) libraries need is just common
sense, that goes without saying, or "is left as
an exercise to the student". In general, you don't
need to null-terminate strings, and that's what
the example goes. Any wrapper to a native library
which _does_ need that should specifically say so.
Got to love "is left as an exercise to the student"
Bug to report: cardinal called an integer
The discussion is mainly a bunch of arguing about what
constitutes a cardinal and what constitutes an integer.
The C String starts again over at:
https://www.nntp.perl.org/group/perl.perl6.users/2020/01/msg7728.html
This was my response:
On 2020-01-14 01:13, JJ Merelo wrote:
> Never miss a good chance to bash documentation...
Guilty as charged?
> 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
Oh Great And Mighty Gatekeeper of the Documentation!
You are in error. The problem is the mistake in the
documentation you won't fix and your misunderstand of
the C programming language.
INTERNATIONAL STANDARD ©ISO/IEC ISO/IEC 9899:201x
Programming languages — C
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
5.2.1 Character sets
:
2 In a character constant or string literal, members
of the execution character set shall be
represented
by corresponding members of the source character
set or by escape
sequences consisting of the
backslash \ followed by one or more characters.
A byte with
all bits set to 0, called the null
character, shall exist in the basic execution
character set; *it
is used to terminate a character
string*.
7.1.1 Definitions of terms
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.
You are basically confusing a "String" with a "String literal".
They are two different things. A String Literal can have
nuls in them that are part of the string literal. And
with a string literal, you have to also keep track of the
length of the string literal.
In WinAPI, calls
https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw
a "string literal" is annotated as:
const BYTE *lpData
And the byte count of such is
DWORD cbData
Note that "*lpData" can be a little endian four byte
DWORD cardial or a UTF16 array of WORDS.
A "C" string (not a string literal) would be
https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regqueryvalueexw
LPCWSTR lpValueName
Are you able to see the difference between "const BYTE *lpData
plus DWORD cbData" and "LPCWSTR lpValueName"? One is
a "String Literal" and the other one is "String".
"LPCWSTR lpValueName" does not need to know the length of the string
because it expects to see a nul at the end.
Your holding on to NOT-A-BUG will mean that everyone
using the documentation will have to figure this all
out the hard way, as I did.
Oh great and exalted Gatekeeper, today you get a C-.
Minus for meanness.
Your favorite Golden Retriever,
-T
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-01-16 01:30 +0000 |
| Message-ID | <87ftggfarv.fsf@bsb.me.uk> |
| In reply to | #149158 |
T <T@invalid.invalid> writes:
> On 2020-01-15 11:33, Keith Thompson wrote:
>> T <T@invalid.invalid> writes:
>>> On 2020-01-15 02:00, Keith Thompson wrote:
>>> I accidentally hit the wrong button and
>>> lost your last letter.
>>>
>>> I now have everything I need. Do you still
>>> want the link to the discussion?
>>
>> Yes. (Wouldn't it have been easier to post the link, or even email
>> it to me, rather than asking whether I still want it?)
>>
>
> Actually, no. I had to do a bunch of detective work.
>
>
> This subject appears in two threads:
>
> NativeCall Doc booboo
> https://www.nntp.perl.org/group/perl.perl6.users/2019/12/msg7586.html
>
> My favorite response was:
>
> It will not be corrected because it's not a
> documentation error. Also, using strings in the way
> your other (native) libraries need is just common
> sense, that goes without saying, or "is left as
> an exercise to the student". In general, you don't
> need to null-terminate strings, and that's what
> the example goes. Any wrapper to a native library
> which _does_ need that should specifically say so.
>
> Got to love "is left as an exercise to the student"
There's not much wrong in that quote as it stands because one can't tell
what a native library actually is. On one system I worked on, "native
code" was Pascal, but it certainly could be some OS interface that used
counted strings.
Reading the thread, however, there seems to be something wrong. Someone
who appears to know stuff is claiming, simply by a working example, that
printf("%s", s); can be called from Raku although the calling code
does not seems to null-terminate the array that is passed. The example
code appears to have got lucky.
I think it's pointless to argue about the words in a mixed-language
context. People are not going to bother about exactly what C calls a
string. The important thing is what should be passed, and in the
example given, an array with a null byte is needed, and the calling code
does not ensure that there is one.
You can get tied up in knots arguing about what "must" be done because
even some C "string" functions can be called without passing a "C
string". For example, printf("%.3s", s); would have been correct in the
example on that page, and strncmp could be called without a null byte in
sight, provided you get the right length.
Furthermore, if Raku strings can legitimately include null bytes (I
think they can), then any C functions called should be specially written
to handle that possibility.
<cut>
> The C String starts again over at:
>
> https://www.nntp.perl.org/group/perl.perl6.users/2020/01/msg7728.html
>
> This was my response:
>
> On 2020-01-14 01:13, JJ Merelo wrote:
>
>> Never miss a good chance to bash documentation...
>
> Guilty as charged?
>
>
>> 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
>
> Oh Great And Mighty Gatekeeper of the Documentation!
>
> You are in error. The problem is the mistake in the
> documentation you won't fix and your misunderstand of
> the C programming language.
The documentation simply looks wrong. It's possible the Raku guarantees
that all CArray[...] objects have zero words after them, but that would
be odd, and I can't see any such guarantee. In fact, I could not find
the documentation for CArray[uint8] anywhere.
<cut quotes from C standard>
> You are basically confusing a "String" with a "String literal".
I did not see evidence for that, but the author does seem to be wrong
about what a string is in C.
> They are two different things. A String Literal can have
> nuls in them that are part of the string literal. And
> with a string literal, you have to also keep track of the
> length of the string literal.
This confused me, but then I read on and you seem to have misunderstood
what a string literal is.
> In WinAPI, calls
>
> https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw
>
> a "string literal" is annotated as:
> const BYTE *lpData
>
> And the byte count of such is
> DWORD cbData
This is not a string literal in any sense at all. A string literal is a
lexical element in a C program text. In the C "abstract machine" it
gives rise to an array in the resulting program, but even that need not
exist in the actual program as compiled. There are no literals (string
or otherwise) in a running program.
In fact lpData (in this call) points to arbitrary data. It may point to
the start of a string or it may not. It could be anything at all.
> Note that "*lpData" can be a little endian four byte
> DWORD cardial or a UTF16 array of WORDS.
Hmm... don't know what you mean. *lpData is an object of type BYTE. It
can be the first byte of just about anything. Maybe that's what you
mean.
> A "C" string (not a string literal) would be
>
> https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regqueryvalueexw
>
> LPCWSTR lpValueName
And this muddies the waters because a pointer to a WCHAR does really map
to anything in the C standard. The closest match is a wide string, but
you've used "C string" to mean a character string up to now.
> Are you able to see the difference between "const BYTE *lpData
> plus DWORD cbData" and "LPCWSTR lpValueName"? One is
> a "String Literal" and the other one is "String".
No. One is a pointer to the first byte of arbitrary data, the second is
a pointer to the start of a wide string.
> "LPCWSTR lpValueName" does not need to know the length of the string
> because it expects to see a nul at the end.
It expects to see a two-byte zero WCHAR at the end. "nul" is the name
of an ASCII character -- just one byte.
> Your holding on to NOT-A-BUG will mean that everyone
> using the documentation will have to figure this all
> out the hard way, as I did.
>
> Oh great and exalted Gatekeeper, today you get a C-.
> Minus for meanness.
There does seem to be some meanness around, but then you are being
dogmatic without having all the facts, and that can wind people up.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-15 18:17 -0800 |
| Message-ID | <qvoh40$psd$1@dont-email.me> |
| In reply to | #149163 |
On 2020-01-15 17:30, Ben Bacarisse wrote:
> T <T@invalid.invalid> writes:
>
>> On 2020-01-15 11:33, Keith Thompson wrote:
>>> T <T@invalid.invalid> writes:
>>>> On 2020-01-15 02:00, Keith Thompson wrote:
>>>> I accidentally hit the wrong button and
>>>> lost your last letter.
>>>>
>>>> I now have everything I need. Do you still
>>>> want the link to the discussion?
>>>
>>> Yes. (Wouldn't it have been easier to post the link, or even email
>>> it to me, rather than asking whether I still want it?)
>>>
>>
>> Actually, no. I had to do a bunch of detective work.
>>
>>
>> This subject appears in two threads:
>>
>> NativeCall Doc booboo
>> https://www.nntp.perl.org/group/perl.perl6.users/2019/12/msg7586.html
>>
>> My favorite response was:
>>
>> It will not be corrected because it's not a
>> documentation error. Also, using strings in the way
>> your other (native) libraries need is just common
>> sense, that goes without saying, or "is left as
>> an exercise to the student". In general, you don't
>> need to null-terminate strings, and that's what
>> the example goes. Any wrapper to a native library
>> which _does_ need that should specifically say so.
>>
>> Got to love "is left as an exercise to the student"
>
> There's not much wrong in that quote as it stands because one can't tell
> what a native library actually is. On one system I worked on, "native
> code" was Pascal, but it certainly could be some OS interface that used
> counted strings.
>
> Reading the thread, however, there seems to be something wrong. Someone
> who appears to know stuff is claiming, simply by a working example, that
> printf("%s", s); can be called from Raku although the calling code
> does not seems to null-terminate the array that is passed. The example
> code appears to have got lucky.
>
> I think it's pointless to argue about the words in a mixed-language
> context. People are not going to bother about exactly what C calls a
> string. The important thing is what should be passed, and in the
> example given, an array with a null byte is needed, and the calling code
> does not ensure that there is one.
>
> You can get tied up in knots arguing about what "must" be done because
> even some C "string" functions can be called without passing a "C
> string". For example, printf("%.3s", s); would have been correct in the
> example on that page, and strncmp could be called without a null byte in
> sight, provided you get the right length.
>
> Furthermore, if Raku strings can legitimately include null bytes (I
> think they can), then any C functions called should be specially written
> to handle that possibility.
>
> <cut>
>> The C String starts again over at:
>>
>> https://www.nntp.perl.org/group/perl.perl6.users/2020/01/msg7728.html
>>
>> This was my response:
>>
>> On 2020-01-14 01:13, JJ Merelo wrote:
>>
>>> Never miss a good chance to bash documentation...
>>
>> Guilty as charged?
>>
>>
>>> 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
>>
>> Oh Great And Mighty Gatekeeper of the Documentation!
>>
>> You are in error. The problem is the mistake in the
>> documentation you won't fix and your misunderstand of
>> the C programming language.
>
> The documentation simply looks wrong. It's possible the Raku guarantees
> that all CArray[...] objects have zero words after them, but that would
> be odd, and I can't see any such guarantee. In fact, I could not find
> the documentation for CArray[uint8] anywhere.
>
> <cut quotes from C standard>
>
>> You are basically confusing a "String" with a "String literal".
>
> I did not see evidence for that, but the author does seem to be wrong
> about what a string is in C.
>
>> They are two different things. A String Literal can have
>> nuls in them that are part of the string literal. And
>> with a string literal, you have to also keep track of the
>> length of the string literal.
>
> This confused me, but then I read on and you seem to have misunderstood
> what a string literal is.
>
>> In WinAPI, calls
>>
>> https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw
>>
>> a "string literal" is annotated as:
>> const BYTE *lpData
>>
>> And the byte count of such is
>> DWORD cbData
>
> This is not a string literal in any sense at all. A string literal is a
> lexical element in a C program text. In the C "abstract machine" it
> gives rise to an array in the resulting program, but even that need not
> exist in the actual program as compiled. There are no literals (string
> or otherwise) in a running program.
>
> In fact lpData (in this call) points to arbitrary data. It may point to
> the start of a string or it may not. It could be anything at all.
And it doe have anything. in teh WinApi call in question it an be either
a little endian DWORD of a little endian UTF16
array of words.
>
>> Note that "*lpData" can be a little endian four byte
>> DWORD cardial or a UTF16 array of WORDS.
>
> Hmm... don't know what you mean. *lpData is an object of type BYTE. It
> can be the first byte of just about anything. Maybe that's what you
> mean.
An array of bytes is the best way to look at it.
>
>> A "C" string (not a string literal) would be
>>
>> https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regqueryvalueexw
>>
>> LPCWSTR lpValueName
>
> And this muddies the waters because a pointer to a WCHAR does really map
> to anything in the C standard. The closest match is a wide string, but
> you've used "C string" to mean a character string up to now.
ya, especially since it is little endian UTF16. And the
second byte is always a nul
>
>> Are you able to see the difference between "const BYTE *lpData
>> plus DWORD cbData" and "LPCWSTR lpValueName"? One is
>> a "String Literal" and the other one is "String".
>
> No. One is a pointer to the first byte of arbitrary data, the second is
> a pointer to the start of a wide string.
Yes, sorry for the confusion.
>> "LPCWSTR lpValueName" does not need to know the length of the string
>> because it expects to see a nul at the end.
>
> It expects to see a two-byte zero WCHAR at the end. "nul" is the name
> of an ASCII character -- just one byte.
With these WinAPI calls, you have to terminate the string with two \0's.
This because the second byte in the UTF words
is always a \0.
Chuckle, we are mixing, Raku with C, with WinAPI.
>
>> Your holding on to NOT-A-BUG will mean that everyone
>> using the documentation will have to figure this all
>> out the hard way, as I did.
>>
>> Oh great and exalted Gatekeeper, today you get a C-.
>> Minus for meanness.
>
> There does seem to be some meanness around, but then you are being
> dogmatic without having all the facts, and that can wind people up.
The guy is a teacher, so I life to tease him about
grades at times. I once called him a Guard Dog as he
is the first line on bug reports and has so far
turned every bug down I posted. Guard Dog is
a figure of speech meaning he is overly protective.
Folks came out of the woodwork claiming I called him
a dog. And no matter many times I explained what I meant,
they kept attacking me for it.
They are not all that way over there. Most of the time they
are real mensches. Sort of like over here.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-01-16 03:44 +0000 |
| Message-ID | <87h80wdpzk.fsf@bsb.me.uk> |
| In reply to | #149166 |
T <T@invalid.invalid> writes: > On 2020-01-15 17:30, Ben Bacarisse wrote: >> T <T@invalid.invalid> writes: <cut> >>> In WinAPI, calls >>> >>> https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw >>> >>> a "string literal" is annotated as: >>> const BYTE *lpData >>> >>> And the byte count of such is >>> DWORD cbData >> >> This is not a string literal in any sense at all. A string literal is a >> lexical element in a C program text. In the C "abstract machine" it >> gives rise to an array in the resulting program, but even that need not >> exist in the actual program as compiled. There are no literals (string >> or otherwise) in a running program. >> >> In fact lpData (in this call) points to arbitrary data. It may point to >> the start of a string or it may not. It could be anything at all. > > And it doe have anything. in teh WinApi call in question it an be > either a little endian DWORD of a little endian UTF16 array of words. Corrected: "In the WinApi call in question it can be either a little endian DWORD or a little endian UTF16 array of words". If that is what you meant, then no, but the reasons why are now way off topic. More on topic is the fact that you are having a go at someone on that list for not confusing strings and string literals, but you don't seem to know what a string literal is. > >> >>> Note that "*lpData" can be a little endian four byte >>> DWORD cardial or a UTF16 array of WORDS. >> >> Hmm... don't know what you mean. *lpData is an object of type BYTE. It >> can be the first byte of just about anything. Maybe that's what you >> mean. > > An array of bytes is the best way to look at it. > >> >>> A "C" string (not a string literal) would be >>> >>> https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regqueryvalueexw >>> >>> LPCWSTR lpValueName >> >> And this muddies the waters because a pointer to a WCHAR does really map (corrected: "does not") >> to anything in the C standard. The closest match is a wide string, but >> you've used "C string" to mean a character string up to now. > > ya, especially since it is little endian UTF16. And the > second byte is always a nul No it isn't. >> >>> Are you able to see the difference between "const BYTE *lpData >>> plus DWORD cbData" and "LPCWSTR lpValueName"? One is >>> a "String Literal" and the other one is "String". >> >> No. One is a pointer to the first byte of arbitrary data, the second is >> a pointer to the start of a wide string. > > Yes, sorry for the confusion. > > >>> "LPCWSTR lpValueName" does not need to know the length of the string >>> because it expects to see a nul at the end. >> >> It expects to see a two-byte zero WCHAR at the end. "nul" is the name >> of an ASCII character -- just one byte. > > With these WinAPI calls, you have to terminate the string with two > \0's. This because the second byte in the UTF words > is always a \0. No, the terminator is, as I said, a zero WCHAR. The notation \0 is doubly confusing because it looks like a C escape, but in a C wide string literal a single \0 denotes a zero of the right size (not that you usually need to write one of course). And no, the second byte is not always zero. <cut> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-15 20:33 -0800 |
| Message-ID | <qvop2m$qr9$1@dont-email.me> |
| In reply to | #149174 |
On 2020-01-15 19:44, Ben Bacarisse wrote: > T <T@invalid.invalid> writes: > >> On 2020-01-15 17:30, Ben Bacarisse wrote: >>> T <T@invalid.invalid> writes: > <cut> >>>> In WinAPI, calls >>>> >>>> https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw >>>> >>>> a "string literal" is annotated as: >>>> const BYTE *lpData >>>> >>>> And the byte count of such is >>>> DWORD cbData >>> >>> This is not a string literal in any sense at all. A string literal is a >>> lexical element in a C program text. In the C "abstract machine" it >>> gives rise to an array in the resulting program, but even that need not >>> exist in the actual program as compiled. There are no literals (string >>> or otherwise) in a running program. >>> >>> In fact lpData (in this call) points to arbitrary data. It may point to >>> the start of a string or it may not. It could be anything at all. >> >> And it doe have anything. in teh WinApi call in question it an be >> either a little endian DWORD of a little endian UTF16 array of words. > > Corrected: "In the WinApi call in question it can be either a little > endian DWORD or a little endian UTF16 array of words". If that is what > you meant, then no, but the reasons why are now way off topic. WinAPI calls ending with an "A" use UTF8. ones ending with "W" use UTF16. I use "W' as there is some noise (rumor) out there that M$ is thinking of dropping "A" support. I have conversion routines for both > More on topic is the fact that you are having a go at someone on that > list for not confusing strings and string literals, but you don't seem > to know what a string literal is. > >> >>> >>>> Note that "*lpData" can be a little endian four byte >>>> DWORD cardial or a UTF16 array of WORDS. >>> >>> Hmm... don't know what you mean. *lpData is an object of type BYTE. It >>> can be the first byte of just about anything. Maybe that's what you >>> mean. >> >> An array of bytes is the best way to look at it. >> >>> >>>> A "C" string (not a string literal) would be >>>> >>>> https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regqueryvalueexw >>>> >>>> LPCWSTR lpValueName >>> >>> And this muddies the waters because a pointer to a WCHAR does really map > (corrected: "does not") >>> to anything in the C standard. The closest match is a wide string, but >>> you've used "C string" to mean a character string up to now. >> >> ya, especially since it is little endian UTF16. And the >> second byte is always a nul > > No it isn't. That is the way I had to program it as I programmed it as bytes. Raku has a habit of turning unsigned integers into regular integers. Messes with teh high bit. They call it "coercing". But Raku leave bytes alone. >>> >>>> Are you able to see the difference between "const BYTE *lpData >>>> plus DWORD cbData" and "LPCWSTR lpValueName"? One is >>>> a "String Literal" and the other one is "String". >>> >>> No. One is a pointer to the first byte of arbitrary data, the second is >>> a pointer to the start of a wide string. >> >> Yes, sorry for the confusion. >> >> >>>> "LPCWSTR lpValueName" does not need to know the length of the string >>>> because it expects to see a nul at the end. >>> >>> It expects to see a two-byte zero WCHAR at the end. "nul" is the name >>> of an ASCII character -- just one byte. >> >> With these WinAPI calls, you have to terminate the string with two >> \0's. This because the second byte in the UTF words >> is always a \0. If you are talking to it as a word, yes. But there are times I have to talk to it as a byte, so two 0's if talking bytes. Raku keeps switching my cardinals (called uint for unsigned integer in Raku) over to signed integers. It can be aggravating as it messes with the high bit. But Raku leaves bytes alone. > No, the terminator is, as I said, a zero WCHAR. The notation \0 is > doubly confusing because it looks like a C escape, but in a C wide > string literal a single \0 denotes a zero of the right size (not that > you usually need to write one of course). > > And no, the second byte is not always zero. True. But what I was calling was the registry and it uses all simple characters, so the second byte was always a 0. No idea why they wanted UTF16. UTF8 would have done fine. Maybe it is a foreign language thing > > <cut> >
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web