Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #149166
| From | T <T@invalid.invalid> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: C String terminator |
| Date | 2020-01-15 18:17 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <qvoh40$psd$1@dont-email.me> (permalink) |
| References | (1 earlier) <87v9pdhwet.fsf@nosuchdomain.example.com> <qvnl2n$tu6$3@dont-email.me> <87eew0ikfe.fsf@nosuchdomain.example.com> <qvnr62$5ln$1@dont-email.me> <87ftggfarv.fsf@bsb.me.uk> |
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.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web