Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #149163
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: C String terminator |
| Date | 2020-01-16 01:30 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <87ftggfarv.fsf@bsb.me.uk> (permalink) |
| References | <qvktc8$gvf$1@dont-email.me> <87v9pdhwet.fsf@nosuchdomain.example.com> <qvnl2n$tu6$3@dont-email.me> <87eew0ikfe.fsf@nosuchdomain.example.com> <qvnr62$5ln$1@dont-email.me> |
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.
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