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

C String terminator

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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →

#149180

From	fir <profesor.fir@gmail.com>
Date	2020-01-16 02:26 -0800
Message-ID	<42573dfd-4060-49ef-84c4-9c2593c1b45c@googlegroups.com>
In reply to	#149158

W dniu środa, 15 stycznia 2020 21:03:22 UTC+1 użytkownik T napisał:
> 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

youre heavily crazy ..if you want to write such battles or what it is (yet in somewhat formal environment i think) you better should know what youre talking about

in rally most cases c string is a strip of memory containig characters identified by adres of the first charater and ended by zero

string literal is like the same but its not meant to ba changed and is previously initialized (in most if not all cases at program init time)..it is generaly meant to be used to be displayed or used as some source of data but is not meant to be changed

in pure typicel c (as i write for example) c makes a heavy usage of string literals (depending on type of aplication, in some totally graphical one that not display text it may use none) and very rare use of mutable strings, except maybe vsnprintf function) 

as string literal is also a string people name it string for short, also they use heavily common name of string which is used to name type of data "strip of letters"

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

#149132

From	Jorgen Grahn <grahn+nntp@snipabacken.se>
Date	2020-01-15 15:11 +0000
Message-ID	<slrnr1uatv.km3.grahn+nntp@frailea.sa.invalid>
In reply to	#149088

On Tue, 2020-01-14, 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.)

If I were you, I'd not argue about the definition of words with these
guys, unless their documentation is misleading.  I'd try to get them
to tell me how to handle string data in that interface.

(That doesn't just mean how to find the length, but also how to handle
things like ownership. I don't know Raku, but with Python 2.x, the C
code had to participate in object reference counting and everything,
some of the time.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#149138

From	T <T@invalid.invalid>
Date	2020-01-15 09:32 -0800
Message-ID	<qvnib5$chh$1@dont-email.me>
In reply to	#149132

On 2020-01-15 07:11, Jorgen Grahn wrote:
> If I were you, I'd not argue about the definition of words with these
> guys, unless their documentation is misleading.

Ya, their conversion utility does not include
a nul terminator, so the arguing continues.
Took me forever to figure out where the strange
characters were coming from.

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

#149151

From	Keith Thompson <Keith.S.Thompson+u@gmail.com>
Date	2020-01-15 10:47 -0800
Message-ID	<87muaoimkt.fsf@nosuchdomain.example.com>
In reply to	#149138

T <T@invalid.invalid> writes:
> On 2020-01-15 07:11, Jorgen Grahn wrote:
>> If I were you, I'd not argue about the definition of words with these
>> guys, unless their documentation is misleading.
>
> Ya, their conversion utility does not include
> a nul terminator, so the arguing continues.
> Took me forever to figure out where the strange
> characters were coming from.

Then your best bet is to put together a small example that
demonstrates a bug.  Arguing about the definitions of terms in
a language that is not the topic of their mailing list might not
be productive.  It might be perfectly reasonable for Raku's native
call interface to accept arguments that don't point to C strings,
or for Raku to use the term "string" to refer to something that
isn't a C string.

-- 
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]

#149155

From	T <T@invalid.invalid>
Date	2020-01-15 10:58 -0800
Message-ID	<qvnncu$ci0$1@dont-email.me>
In reply to	#149151

On 2020-01-15 10:47, Keith Thompson wrote:
> T <T@invalid.invalid> writes:
>> On 2020-01-15 07:11, Jorgen Grahn wrote:
>>> If I were you, I'd not argue about the definition of words with these
>>> guys, unless their documentation is misleading.
>>
>> Ya, their conversion utility does not include
>> a nul terminator, so the arguing continues.
>> Took me forever to figure out where the strange
>> characters were coming from.
> 
> Then your best bet is to put together a small example that
> demonstrates a bug.  Arguing about the definitions of terms in
> a language that is not the topic of their mailing list might not
> be productive.  It might be perfectly reasonable for Raku's native
> call interface to accept arguments that don't point to C strings,
> or for Raku to use the term "string" to refer to something that
> isn't a C string.
> 

I EVEN sent the gatekeeper PICTURES!

https://ibb.co/tHy7ZQM

Water off the back of a duck.

This is why I wanted chapter and verse of the C
specification

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

#149164

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2020-01-16 01:39 +0000
Message-ID	<87a76ofad3.fsf@bsb.me.uk>
In reply to	#149155

T <T@invalid.invalid> writes:

> On 2020-01-15 10:47, Keith Thompson wrote:
>> T <T@invalid.invalid> writes:
>>> On 2020-01-15 07:11, Jorgen Grahn wrote:
>>>> If I were you, I'd not argue about the definition of words with these
>>>> guys, unless their documentation is misleading.
>>>
>>> Ya, their conversion utility does not include
>>> a nul terminator, so the arguing continues.
>>> Took me forever to figure out where the strange
>>> characters were coming from.
>>
>> Then your best bet is to put together a small example that
>> demonstrates a bug.  Arguing about the definitions of terms in
>> a language that is not the topic of their mailing list might not
>> be productive.  It might be perfectly reasonable for Raku's native
>> call interface to accept arguments that don't point to C strings,
>> or for Raku to use the term "string" to refer to something that
>> isn't a C string.
>>
>
> I EVEN sent the gatekeeper PICTURES!
>
> https://ibb.co/tHy7ZQM

That would not convince me, and I know you are right about this!  You
need code, not pictures of output.  (Maybe you posted the code, but
didn't see it.)

I tried my own example based on the printf one given the the Raku
discussion, but it worked.  Luck, I imagine, but incorrect code often
works.

-- 
Ben.

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

#149169

From	T <T@invalid.invalid>
Date	2020-01-15 18:27 -0800
Message-ID	<qvohm6$rt5$1@dont-email.me>
In reply to	#149164

On 2020-01-15 17:39, Ben Bacarisse wrote:
> T <T@invalid.invalid> writes:
> 
>> On 2020-01-15 10:47, Keith Thompson wrote:
>>> T <T@invalid.invalid> writes:
>>>> On 2020-01-15 07:11, Jorgen Grahn wrote:
>>>>> If I were you, I'd not argue about the definition of words with these
>>>>> guys, unless their documentation is misleading.
>>>>
>>>> Ya, their conversion utility does not include
>>>> a nul terminator, so the arguing continues.
>>>> Took me forever to figure out where the strange
>>>> characters were coming from.
>>>
>>> Then your best bet is to put together a small example that
>>> demonstrates a bug.  Arguing about the definitions of terms in
>>> a language that is not the topic of their mailing list might not
>>> be productive.  It might be perfectly reasonable for Raku's native
>>> call interface to accept arguments that don't point to C strings,
>>> or for Raku to use the term "string" to refer to something that
>>> isn't a C string.
>>>
>>
>> I EVEN sent the gatekeeper PICTURES!
>>
>> https://ibb.co/tHy7ZQM
> 
> That would not convince me, and I know you are right about this!  You
> need code, not pictures of output.  (Maybe you posted the code, but
> didn't see it.)

I was trying to show him that if you did not properly
terminate your C String, that the Win API call would
careen through memory until it found its of nul.

I did post the code.  I got my s*** jumped into for flooding
the group.  Some of the nice ones told me to take it to
GIT.  That is probably a good idea.

If you would like to see it, I will post it to vpaste.net.
But it is hundred and hundred of lines.  Basically four modules
concerning various WinAPI calls I need fro a project.

> 
> I tried my own example based on the printf one given the the Raku
> discussion, but it worked.  Luck, I imagine, but incorrect code often
> works.

And there is lies the problem.  Their examples work,
but do not work in the real world.  And as far as
they are concerned, if the samples work, there is
no issue.  I guess we look at the purpose of the
documentation differently.  I see it as tool to
help me use the function.  They obviously do not.

They also argue with me endlessly that this is
not a Raku problem.  And I argue back that
if the Module interfaces with C, you have to
had BETTER discuss BOTH in your manual.  I am
writing my own how to to help others.  I am about a
month away from finishing.

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

#149170

From	T <T@invalid.invalid>
Date	2020-01-15 19:03 -0800
Message-ID	<qvojpl$56e$1@dont-email.me>
In reply to	#149169

On 2020-01-15 18:27, T wrote:
> On 2020-01-15 17:39, Ben Bacarisse wrote:
>> T <T@invalid.invalid> writes:
>>
>>> On 2020-01-15 10:47, Keith Thompson wrote:
>>>> T <T@invalid.invalid> writes:
>>>>> On 2020-01-15 07:11, Jorgen Grahn wrote:
>>>>>> If I were you, I'd not argue about the definition of words with these
>>>>>> guys, unless their documentation is misleading.
>>>>>
>>>>> Ya, their conversion utility does not include
>>>>> a nul terminator, so the arguing continues.
>>>>> Took me forever to figure out where the strange
>>>>> characters were coming from.
>>>>
>>>> Then your best bet is to put together a small example that
>>>> demonstrates a bug.  Arguing about the definitions of terms in
>>>> a language that is not the topic of their mailing list might not
>>>> be productive.  It might be perfectly reasonable for Raku's native
>>>> call interface to accept arguments that don't point to C strings,
>>>> or for Raku to use the term "string" to refer to something that
>>>> isn't a C string.
>>>>
>>>
>>> I EVEN sent the gatekeeper PICTURES!
>>>
>>> https://ibb.co/tHy7ZQM
>>
>> That would not convince me, and I know you are right about this!  You
>> need code, not pictures of output.  (Maybe you posted the code, but
>> didn't see it.)
> 
> I was trying to show him that if you did not properly
> terminate your C String, that the Win API call would
> careen through memory until it found its of nul.
> 
> I did post the code.  I got my s*** jumped into for flooding
> the group.  Some of the nice ones told me to take it to
> GIT.  That is probably a good idea.
> 
> If you would like to see it, I will post it to vpaste.net.
> But it is hundred and hundred of lines.  Basically four modules
> concerning various WinAPI calls I need fro a project.
> 
>>
>> I tried my own example based on the printf one given the the Raku
>> discussion, but it worked.  Luck, I imagine, but incorrect code often
>> works.
> 
> And there is lies the problem.  Their examples work,
> but do not work in the real world.  And as far as
> they are concerned, if the samples work, there is
> no issue.  I guess we look at the purpose of the
> documentation differently.  I see it as tool to
> help me use the function.  They obviously do not.
> 
> They also argue with me endlessly that this is
> not a Raku problem.  And I argue back that
> if the Module interfaces with C, you have to
> had BETTER discuss BOTH in your manual.  I am
> writing my own how to to help others.  I am about a
> month away from finishing.


You know, that on is not all that damned long: 141
lines.  And I ever give a sample call for it.

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

#149171

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2020-01-16 03:28 +0000
Message-ID	<87muaodqqn.fsf@bsb.me.uk>
In reply to	#149169

T <T@invalid.invalid> writes:

> On 2020-01-15 17:39, Ben Bacarisse wrote:
>> T <T@invalid.invalid> writes:
>>
>>> On 2020-01-15 10:47, Keith Thompson wrote:
>>>> T <T@invalid.invalid> writes:
>>>>> On 2020-01-15 07:11, Jorgen Grahn wrote:
>>>>>> If I were you, I'd not argue about the definition of words with these
>>>>>> guys, unless their documentation is misleading.
>>>>>
>>>>> Ya, their conversion utility does not include
>>>>> a nul terminator, so the arguing continues.
>>>>> Took me forever to figure out where the strange
>>>>> characters were coming from.
>>>>
>>>> Then your best bet is to put together a small example that
>>>> demonstrates a bug.  Arguing about the definitions of terms in
>>>> a language that is not the topic of their mailing list might not
>>>> be productive.  It might be perfectly reasonable for Raku's native
>>>> call interface to accept arguments that don't point to C strings,
>>>> or for Raku to use the term "string" to refer to something that
>>>> isn't a C string.
>>>>
>>>
>>> I EVEN sent the gatekeeper PICTURES!
>>>
>>> https://ibb.co/tHy7ZQM
>>
>> That would not convince me, and I know you are right about this!  You
>> need code, not pictures of output.  (Maybe you posted the code, but
>> didn't see it.)
>
> I was trying to show him that if you did not properly
> terminate your C String, that the Win API call would
> careen through memory until it found its of nul.
>
> I did post the code.  I got my s*** jumped into for flooding
> the group.  Some of the nice ones told me to take it to
> GIT.  That is probably a good idea.
>
> If you would like to see it, I will post it to vpaste.net.
> But it is hundred and hundred of lines.  Basically four modules
> concerning various WinAPI calls I need fro a project.

I don't need to see it.  Also you can't really support a bug report with
hundreds of lines of code.

Your best bet is to submit a patch to the documentation.  Note that all
the example code needs is and extra ", 0":

  my $array = CArray[uint8].new($string.encode.list, 0);

and a note to the effect that, in general, character arrays passed to C
functions taking strings should be null-terminated.

The example in the documentation is not actually wrong because it is
possible that the C function knows or can assume the length of the
usable data.  It's just a bad example as it's not really general.

-- 
Ben.

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

#149172

From	T <T@invalid.invalid>
Date	2020-01-15 19:33 -0800
Message-ID	<qvolil$db7$1@dont-email.me>
In reply to	#149171

On 2020-01-15 19:28, Ben Bacarisse wrote:
>   my $array = CArray[uint8].new($string.encode.list, 0);

I love it!

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

#149173

From	T <T@invalid.invalid>
Date	2020-01-15 19:38 -0800
Message-ID	<qvolrg$ean$1@dont-email.me>
In reply to	#149171

On 2020-01-15 19:28, Ben Bacarisse wrote:
> T <T@invalid.invalid> writes:
> 
>> On 2020-01-15 17:39, Ben Bacarisse wrote:
>>> T <T@invalid.invalid> writes:
>>>
>>>> On 2020-01-15 10:47, Keith Thompson wrote:
>>>>> T <T@invalid.invalid> writes:
>>>>>> On 2020-01-15 07:11, Jorgen Grahn wrote:
>>>>>>> If I were you, I'd not argue about the definition of words with these
>>>>>>> guys, unless their documentation is misleading.
>>>>>>
>>>>>> Ya, their conversion utility does not include
>>>>>> a nul terminator, so the arguing continues.
>>>>>> Took me forever to figure out where the strange
>>>>>> characters were coming from.
>>>>>
>>>>> Then your best bet is to put together a small example that
>>>>> demonstrates a bug.  Arguing about the definitions of terms in
>>>>> a language that is not the topic of their mailing list might not
>>>>> be productive.  It might be perfectly reasonable for Raku's native
>>>>> call interface to accept arguments that don't point to C strings,
>>>>> or for Raku to use the term "string" to refer to something that
>>>>> isn't a C string.
>>>>>
>>>>
>>>> I EVEN sent the gatekeeper PICTURES!
>>>>
>>>> https://ibb.co/tHy7ZQM
>>>
>>> That would not convince me, and I know you are right about this!  You
>>> need code, not pictures of output.  (Maybe you posted the code, but
>>> didn't see it.)
>>
>> I was trying to show him that if you did not properly
>> terminate your C String, that the Win API call would
>> careen through memory until it found its of nul.
>>
>> I did post the code.  I got my s*** jumped into for flooding
>> the group.  Some of the nice ones told me to take it to
>> GIT.  That is probably a good idea.
>>
>> If you would like to see it, I will post it to vpaste.net.
>> But it is hundred and hundred of lines.  Basically four modules
>> concerning various WinAPI calls I need fro a project.
> 
> I don't need to see it.  Also you can't really support a bug report with
> hundreds of lines of code.
> 
> Your best bet is to submit a patch to the documentation.  Note that all
> the example code needs is and extra ", 0":
> 
>    my $array = CArray[uint8].new($string.encode.list, 0);

Sweet!  I like it!  I am just included it in my paper.

By the way
     my $array = CArray[uint16].new($string.encode.list, 0);
the "0" at the end puts a zero in both bytes of teh last
word, which is perfect.


> and a note to the effect that, in general, character arrays passed to C
> functions taking strings should be null-terminated.
> 
> The example in the documentation is not actually wrong because it is
> possible that the C function knows or can assume the length of the
> usable data.  

You are asking for the C function to go careening.  It
is really bad practice.  Also, the C guys told those
functions that can figure out on the own are not
actually called a string function.  I can try to
find what they called it, just the wrote me a ton stuff.

> It's just a bad example as it's not really general.

JJ's point is that it works in the example, so it is not
an error.  My point is that the documentation should help
the reader understand how to use the thing in practice.
I lost.

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

#149186

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2020-01-16 13:31 +0000
Message-ID	<87zhencyud.fsf@bsb.me.uk>
In reply to	#149173

T <T@invalid.invalid> writes:

> By the way
>     my $array = CArray[uint16].new($string.encode.list, 0);
> the "0" at the end puts a zero in both bytes of teh last
> word, which is perfect.

Yes, how could it not?  Mind you, it seems an odd way to express it.
The 0 puts a zero into the array, nothing more, nothing less.

> On 2020-01-15 19:28, Ben Bacarisse wrote:
>> and a note to the effect that, in general, character arrays passed to C
>> functions taking strings should be null-terminated.
>>
>> The example in the documentation is not actually wrong because it is
>> possible that the C function knows or can assume the length of the
>> usable data.  
>
> You are asking for the C function to go careening.  It
> is really bad practice.

I'm just pointing out that the example is not self-evidently wrong --
it's not asking for the C function to go careening off.

If you want to be heard, make sure your criticism is correct.  I agree
it's bad practice but you just can't say, from the example in the
documentation, that either called C function will go wrong.

> Also, the C guys told those
> functions that can figure out on the own are not
> actually called a string function.  I can try to
> find what they called it, just the wrote me a ton stuff.

So what?  Anyway, the example does not call set_foo (one of the C
functions called) a "string function".  What's more, there are some
functions (like strncmp) that C documents as "string handling" functions
but which don't need a null-terminated array to be passed.

You just get tied in knots about terms getting nowhere.  For the greater
good, the best option is simply to get a better example into the
documentation.

>> It's just a bad example as it's not really general.
>
> JJ's point is that it works in the example, so it is not
> an error.  My point is that the documentation should help
> the reader understand how to use the thing in practice.
> I lost.

You have not yet achieved your goal!  Can you submit a patch to the
documentation?

-- 
Ben.

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

#149193

From	T <T@invalid.invalid>
Date	2020-01-16 09:09 -0800
Message-ID	<qvq5bm$pki$1@dont-email.me>
In reply to	#149186

On 2020-01-16 05:31, Ben Bacarisse wrote:
> You have not yet achieved your goal!  Can you submit a patch to the
> documentation?

I got shot down by the first responder before I even
got that far.  If the example works, then there is
not bug.  The correspondence was with him

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

#149194

From	Joe Pfeiffer <pfeiffer@cs.nmsu.edu>
Date	2020-01-16 10:27 -0700
Message-ID	<1by2u7s456.fsf@pfeifferfamily.net>
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.  If the example works, then there is
> not bug.  The correspondence was with him

Then you need to concoct a simple example that does not work.

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

#149199

From	T <T@invalid.invalid>
Date	2020-01-16 10:54 -0800
Message-ID	<qvqbgm$cdt$1@dont-email.me>
In reply to	#149194

On 2020-01-16 09:27, Joe Pfeiffer 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.  If the example works, then there is
>> not bug.  The correspondence was with him
> 
> Then you need to concoct a simple example that does not work.

In a different culture, you would be absolutely
correct.

Actually, he does not care, unless the example
is in the documentation does not work.  And
adding a better example to the documentation
is not going to happen.  It is a different culture
than you (or I) are use to.

And if I could actually get a better example into
the docs, I would ask you guys for a system call
that borked on an unterminated string.  But the
odds of them changing the documentation is zero, so
I going to waste you guys' time.

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

#149204

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2020-01-16 20:59 +0000
Message-ID	<87d0bjce2h.fsf@bsb.me.uk>
In reply to	#149199

T <T@invalid.invalid> writes:
<cut>
> And if I could actually get a better example into
> the docs, I would ask you guys for a system call
> that borked on an unterminated string.  But the
> odds of them changing the documentation is zero, so
> I going to waste you guys' time.

That's not the point.  There is already and accepted example, posted by
the person you need to persuade no less, that will go demonstrably wrong
when passed an unterminated string.  The problem is getting Raku to pass
such a string.  As such you would need to talk to Raku people, not C
people.

-- 
Ben.

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

#149206

From	T <T@invalid.invalid>
Date	2020-01-16 14:11 -0800
Message-ID	<qvqn3d$3kq$1@dont-email.me>
In reply to	#149204

On 2020-01-16 12:59, Ben Bacarisse wrote:
> T <T@invalid.invalid> writes:
> <cut>
>> And if I could actually get a better example into
>> the docs, I would ask you guys for a system call
>> that borked on an unterminated string.  But the
>> odds of them changing the documentation is zero, so
>> I going to waste you guys' time.
> 
> That's not the point.  There is already and accepted example, posted by
> the person you need to persuade no less, that will go demonstrably wrong
> when passed an unterminated string.  The problem is getting Raku to pass
> such a string.  As such you would need to talk to Raku people, not C
> people.
> 

You are absolutely correct.  And to talk
to the Raku folks, I need to have all my facts
straight.  That is what this post is all about.

And as far as the guy wrote that document, he
does not care much for me.  He took the complaint
about the accuracy of the page as a personal insult.
He is not changing it short of an act of God.  Or
someone higher up than him over rules him.

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

#149201

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2020-01-16 20:17 +0000
Message-ID	<87o8v3cg0i.fsf@bsb.me.uk>
In reply to	#149194

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> T <T@invalid.invalid> writes:
>
>> On 2020-01-16 05:31, Ben Bacarisse wrote:
>>> You have not yet achieved your goal!  Can you submit a patch to the
>>> documentation?
>>
>> I got shot down by the first responder before I even
>> got that far.  If the example works, then there is
>> not bug.  The correspondence was with him
>
> Then you need to concoct a simple example that does not work.

That's not always easy.  I may be very hard indeed.  Here's a C example:

$ cat t.c
#include <stdio.h>

void foo(const char *s)
{
     printf("[%s]\n", s);
}

int main(void)
{
     char str[3] = "FOO";
     foo(str); // DANGER, WILL ROBINSON!
}
$ gcc -o t t.c
$ ./t
[FOO]

All must be well because it works!  It's even harder when the C function
is called from a high-level language where there is far less chance to
control data layout etc.

People should accept a simple, well-argued claim that something is
wrong.

-- 
Ben.

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

#149207

From	T <T@invalid.invalid>
Date	2020-01-16 14:14 -0800
Message-ID	<qvqn8b$3kq$2@dont-email.me>
In reply to	#149201

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

Hi Ben,

I am a total idiot when it comes to C.  How do
I run this?

Does char str[3] = "FOO"; mean there cells (bytes?)
or 4 [0..3]?

-T

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

#149209

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2020-01-16 23:45 +0000
Message-ID	<877e1rc6f7.fsf@bsb.me.uk>
In reply to	#149207

T <T@invalid.invalid> writes:

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

I don't know.  That depends on your compiler, OS and so on and that
obviously different to mine sice whole process of compiling and running
is shown above.

> Does char str[3] = "FOO"; mean there cells (bytes?)
> or 4 [0..3]?

char is C's name for a byte.  The number in an array type is the number
of objects in the array, so str is an array or three bytes, indexed from
0 to 2 inclusive.

-- 
Ben.

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

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

csiph-web

C String terminator

Contents

#149180

#149132

#149138

#149151

#149155

#149164

#149169

#149170

#149171

#149172

#149173

#149186

#149193

#149194

#149199

#149204

#149206

#149201

#149207

#149209