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 1 of 6 [1] 2 3 4 5 6 Next page →
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-14 09:22 -0800 |
| Subject | C String terminator |
| Message-ID | <qvktc8$gvf$1@dont-email.me> |
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.)
[toc] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-01-14 09:32 -0800 |
| Message-ID | <303beb4a-dd99-4dbd-bbb7-eb8a07632526@googlegroups.com> |
| In reply to | #149088 |
On Tuesday, 14 January 2020 17:22:24 UTC, 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.) > Generally when we use the term "C string" we mean a nul-terminated string with 8 bit characters, or coded in UTF-8. However the C language allows you to construct strings in memory which are not nul terminated. These won't work as expected with printf() or any of the other C string handling functions. However you can write alternatives to these functions that operate on counted strings, or whatever alternative you have chosen.
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-14 09:43 -0800 |
| Message-ID | <qvkuje$o6g$1@dont-email.me> |
| In reply to | #149089 |
On 2020-01-14 09:32, Malcolm McLean wrote: > On Tuesday, 14 January 2020 17:22:24 UTC, 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.) >> > Generally when we use the term "C string" we mean a nul-terminated string > with 8 bit characters, or coded in UTF-8. > However the C language allows you to construct strings in memory which are > not nul terminated. These won't work as expected with printf() or any > of the other C string handling functions. However you can write alternatives > to these functions that operate on counted strings, or whatever > alternative you have chosen. > So in other words, if y create a customer array of bytes and have another variable somewhere to keep track of its length, you don't have to terminate it with a nul. Am I correct? And good luck stopping a WinAPI call from careening until it finds a nul if you don't nul terminate it. Any idea where in the ISO the nul is documented?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-14 17:53 +0000 |
| Message-ID | <lenTF.58611$5X1.6994@fx06.am4> |
| In reply to | #149090 |
On 14/01/2020 17:43, T wrote: > On 2020-01-14 09:32, Malcolm McLean wrote: >> On Tuesday, 14 January 2020 17:22:24 UTC, 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.) >>> >> Generally when we use the term "C string" we mean a nul-terminated string >> with 8 bit characters, or coded in UTF-8. >> However the C language allows you to construct strings in memory which >> are >> not nul terminated. These won't work as expected with printf() or any >> of the other C string handling functions. However you can write >> alternatives >> to these functions that operate on counted strings, or whatever >> alternative you have chosen. >> > > So in other words, if y create a customer array of bytes > and have another variable somewhere to keep track of > its length, you don't have to terminate it with a > nul. Am I correct? > > And good luck stopping a WinAPI call from careening > until it finds a nul if you don't nul terminate it. Most functions in libraries that take a char* that represents text, expect it to be nul-terminated. I find that a nuisance as I make extensive use of either counted strings (with attached length) or strings with a length stored separately. Calling an API function requiring a terminating string, means allocating N+1 bytes, copying the string into it, adding the terminator, then passing that block. Then deallocating when done.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-14 20:17 +0100 |
| Message-ID | <qvl43g$up6$1@dont-email.me> |
| In reply to | #149091 |
On 14/01/2020 18:53, Bart wrote: > On 14/01/2020 17:43, T wrote: >> On 2020-01-14 09:32, Malcolm McLean wrote: >>> On Tuesday, 14 January 2020 17:22:24 UTC, 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.) >>>> >>> Generally when we use the term "C string" we mean a nul-terminated >>> string >>> with 8 bit characters, or coded in UTF-8. >>> However the C language allows you to construct strings in memory >>> which are >>> not nul terminated. These won't work as expected with printf() or any >>> of the other C string handling functions. However you can write >>> alternatives >>> to these functions that operate on counted strings, or whatever >>> alternative you have chosen. >>> >> >> So in other words, if y create a customer array of bytes >> and have another variable somewhere to keep track of >> its length, you don't have to terminate it with a >> nul. Am I correct? >> >> And good luck stopping a WinAPI call from careening >> until it finds a nul if you don't nul terminate it. > > Most functions in libraries that take a char* that represents text, > expect it to be nul-terminated. > > I find that a nuisance as I make extensive use of either counted strings > (with attached length) or strings with a length stored separately. > > Calling an API function requiring a terminating string, means allocating > N+1 bytes, copying the string into it, adding the terminator, then > passing that block. Then deallocating when done. People could say exactly the same thing about working with Pascal strings when they have a C string. If you find you are often doing such conversions, why not just make sure you have N + 2 bytes of space in the first place? Your first extra byte is the length (limited to 255 byte strings), then comes the data. And you can just do "s[s[0]] = 0" to get the null termination before calling the C function (with s + 1 as the address).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-14 20:01 +0000 |
| Message-ID | <36pTF.41448$0S3.33264@fx38.am4> |
| In reply to | #149095 |
On 14/01/2020 19:17, David Brown wrote: > On 14/01/2020 18:53, Bart wrote: >> On 14/01/2020 17:43, T wrote: >>> And good luck stopping a WinAPI call from careening >>> until it finds a nul if you don't nul terminate it. >> >> Most functions in libraries that take a char* that represents text, >> expect it to be nul-terminated. >> >> I find that a nuisance as I make extensive use of either counted >> strings (with attached length) or strings with a length stored >> separately. >> >> Calling an API function requiring a terminating string, means >> allocating N+1 bytes, copying the string into it, adding the >> terminator, then passing that block. Then deallocating when done. > > People could say exactly the same thing about working with Pascal > strings when they have a C string. > > If you find you are often doing such conversions, why not just make sure > you have N + 2 bytes of space in the first place? Your first extra byte > is the length (limited to 255 byte strings), then comes the data. And > you can just do "s[s[0]] = 0" to get the null termination before calling > the C function (with s + 1 as the address). This only really works for certain kinds of strings. For example, when you are dealing with an entire, self-contained string when it is not part of a larger object, or a larger string. If the counted string involved is a field of a struct, and it needs to have and be able to use all N bytes of its length, there is no room to put a terminator for any string of length N. (Here, there are ways to have a string count, and to use all bytes; to use such string involves constructing a (pointer,length) descriptor, but adding a terminator involves duplicating it.) But most importantly, when the counted string is a slice to a substring which is in the middle of another string, you can't write past the end of it to add a zero. Even for independent strings, ensuring space for a terminator can mean double the allocation space when a string already contains 2**N characters, depending on allocation strategy. This also also complicates management: you are not dealing with N bytes of its length, but N+1 bytes. Empty strings that normally are dealt with simply by N=0 (and there is no pointer), for passing to C functions require special-casing and providing either NULL or "".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-01-14 09:57 -0800 |
| Message-ID | <7b60b22b-5f08-418a-a9af-e1b9a11c1626@googlegroups.com> |
| In reply to | #149090 |
On Tuesday, 14 January 2020 17:43:19 UTC, T wrote: > On 2020-01-14 09:32, Malcolm McLean wrote: > > On Tuesday, 14 January 2020 17:22:24 UTC, 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.) > >> > > Generally when we use the term "C string" we mean a nul-terminated string > > with 8 bit characters, or coded in UTF-8. > > However the C language allows you to construct strings in memory which are > > not nul terminated. These won't work as expected with printf() or any > > of the other C string handling functions. However you can write alternatives > > to these functions that operate on counted strings, or whatever > > alternative you have chosen. > > > > So in other words, if y create a customer array of bytes > and have another variable somewhere to keep track of > its length, you don't have to terminate it with a > nul. Am I correct? > > And good luck stopping a WinAPI call from careening > until it finds a nul if you don't nul terminate it. > Yes. Although you actually give a bad example. Quite a lot of Windows API calls take a length parameter instead of assuming that a string is nul- terminated. That's for historical reasons when the Win API wasn't specificlaly designed for C. > > Any idea where in the ISO the nul is documented? > From one version of the standard In translation phase 7, a byte or code of value zero is appended to each multibytecharacter sequence that results from a string literal or literals. It's in the section "string literals", 6.4.5
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-14 11:37 -0800 |
| Message-ID | <87d0blkexd.fsf@nosuchdomain.example.com> |
| In reply to | #149092 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 14 January 2020 17:43:19 UTC, T wrote:
[...]
>> Any idea where in the ISO the nul is documented?
>>
> From one version of the standard
>
> In translation phase 7, a byte or code of value zero is appended to
> each multibytecharacter sequence that results from a string literal or
> literals.
>
> It's in the section "string literals", 6.4.5
That's not directly relevant. String literals and strings are two
different things. String literals in source code *usually* result in
strings at run time, but not always. For example, the string literal
"foo\0bar" results in an 8-character array whose contents are not a
string. And there are plenty of ways to construct strings without using
string literals:
char s[4];
s[0] = 'f';
s[1] = 'o';
s[2] = 'o';
s[3] = 0;
The answer to the OP's question is 7.1.1 paragraph 1:
A *string* is a contiguous sequence of characters terminated by and
including the first null character.
The word "string" is in italics, so that's the definition of the term.
You can certainly have arrays of characters that are not terminated
by a null character, but such an array (or rather its content)
is not a "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]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-15 09:02 -0800 |
| Message-ID | <qvngin$vbv$1@dont-email.me> |
| In reply to | #149097 |
On 2020-01-14 11:37, Keith Thompson wrote: > The answer to the OP's question is 7.1.1 paragraph 1: Hi Keith, Do you have a link to that paragraph? -T
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-15 09:38 -0800 |
| Message-ID | <qvnilp$e9v$1@dont-email.me> |
| In reply to | #149136 |
On 2020-01-15 09:02, T wrote: > On 2020-01-14 11:37, Keith Thompson wrote: >> The answer to the OP's question is 7.1.1 paragraph 1: > > Hi Keith, > > Do you have a link to that paragraph? > > -T ??? http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
[toc] | [prev] | [next] | [standalone]
| From | T <T@invalid.invalid> |
|---|---|
| Date | 2020-01-15 09:53 -0800 |
| Message-ID | <qvnjik$kld$1@dont-email.me> |
| In reply to | #149140 |
On 2020-01-15 09:38, T wrote: > On 2020-01-15 09:02, T wrote: >> On 2020-01-14 11:37, Keith Thompson wrote: >>> The answer to the OP's question is 7.1.1 paragraph 1: >> >> Hi Keith, >> >> Do you have a link to that paragraph? >> >> -T > > > ??? > > 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 | Manfred <noname@add.invalid> |
|---|---|
| Date | 2020-01-14 20:48 +0100 |
| Message-ID | <qvl5v8$53e$1@gioia.aioe.org> |
| In reply to | #149092 |
On 1/14/2020 6:57 PM, Malcolm McLean wrote: > On Tuesday, 14 January 2020 17:43:19 UTC, T wrote: >> On 2020-01-14 09:32, Malcolm McLean wrote: >>> On Tuesday, 14 January 2020 17:22:24 UTC, 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.) >>>> >>> Generally when we use the term "C string" we mean a nul-terminated string >>> with 8 bit characters, or coded in UTF-8. >>> However the C language allows you to construct strings in memory which are >>> not nul terminated. These won't work as expected with printf() or any >>> of the other C string handling functions. However you can write alternatives >>> to these functions that operate on counted strings, or whatever >>> alternative you have chosen. >>> >> >> So in other words, if y create a customer array of bytes >> and have another variable somewhere to keep track of >> its length, you don't have to terminate it with a >> nul. Am I correct? >> >> And good luck stopping a WinAPI call from careening >> until it finds a nul if you don't nul terminate it. >> > Yes. Although you actually give a bad example. Quite a lot of Windows API > calls take a length parameter instead of assuming that a string is nul- > terminated. That's for historical reasons when the Win API wasn't > specificlaly designed for C. >> >> Any idea where in the ISO the nul is documented? >> > From one version of the standard > > > In translation phase 7, a byte or code of value zero is appended to each multibytecharacter sequence that results from a string literal or literals. > > It's in the section "string literals", 6.4.5 > From n1570: Section 5.2.1 "Character sets", p2, definition of null character: "... 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" Section 7 "Library", 7.1.1 "Definition of terms", definition of string: "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." This definition applies to the section about the standard library. As other have said, it is possible to handle other kinds of text data (e.g. counted strings) by writing the appropriate C code - in this case the text data would be substantially a raw byte array that is handled (as text) by the application code. However, the standard library (which is part of the C standard) defines strings as above, which is the layout that is required for text data to be handled by the standard library (unless there are any exceptions from this in the standard library that I am missing, but that's substantially it).
[toc] | [prev] | [next] | [standalone]
| From | chad <cdalten@gmail.com> |
|---|---|
| Date | 2020-01-15 05:43 -0800 |
| Message-ID | <08b3c819-2712-4ea4-b4ae-aae81066ebcd@googlegroups.com> |
| In reply to | #149089 |
On Tuesday, January 14, 2020 at 9:33:01 AM UTC-8, Malcolm McLean wrote: > On Tuesday, 14 January 2020 17:22:24 UTC, 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.) > > > Generally when we use the term "C string" we mean a nul-terminated string > with 8 bit characters, or coded in UTF-8. > However the C language allows you to construct strings in memory which are > not nul terminated. These won't work as expected with printf() or any > of the other C string handling functions. However you can write alternatives > to these functions that operate on counted strings, or whatever > alternative you have chosen. Maybe this is too early in the morning yet, but how would this work if it's not coded in UTF-8? This is because I encountered a similar problem when coding stuff for Facebook. Basically the system didn't have UTF-8 encoding. As a result, I went by another person's solution and converted the corresponding string into Unicode. This is because the system can read Unicode, but not UTF-8.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-01-15 07:12 -0800 |
| Message-ID | <5b73eb93-316d-4dd8-83f7-2af0d9e244e7@googlegroups.com> |
| In reply to | #149125 |
On Wednesday, 15 January 2020 13:43:56 UTC, chad wrote: > On Tuesday, January 14, 2020 at 9:33:01 AM UTC-8, Malcolm McLean wrote: > > On Tuesday, 14 January 2020 17:22:24 UTC, 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.) > > > > > Generally when we use the term "C string" we mean a nul-terminated string > > with 8 bit characters, or coded in UTF-8. > > However the C language allows you to construct strings in memory which are > > not nul terminated. These won't work as expected with printf() or any > > of the other C string handling functions. However you can write alternatives > > to these functions that operate on counted strings, or whatever > > alternative you have chosen. > > Maybe this is too early in the morning yet, but how would this work if > it's not coded in UTF-8? This is because I encountered a similar problem > when coding stuff for Facebook. Basically the system didn't have UTF-8 > encoding. As a result, I went by another person's solution and converted > the corresponding string into Unicode. This is because the system can read > Unicode, but not UTF-8. > K and R, when they were designing C, made the mistake of assuming that all machines would have Latin character sets which fit in a byte. So instead of calling the smallest data type "byte", they called it "char", then they made all the string functions take char *s. Theoretically it is possible to make chars 16 bit and support Unicode that way, but I don't think anybody actually does that. Instead there's a wide character type typedefed, then functions with names like wprintf() are provided. An all zero wide character is still used to indicate string termination, however.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-01-15 15:35 +0000 |
| Message-ID | <slrnr1ucat.km3.grahn+nntp@frailea.sa.invalid> |
| In reply to | #149125 |
On Wed, 2020-01-15, chad wrote: > On Tuesday, January 14, 2020 at 9:33:01 AM UTC-8, Malcolm McLean wrote: ... >> Generally when we use the term "C string" we mean a nul-terminated string >> with 8 bit characters, or coded in UTF-8. ... > Maybe this is too early in the morning yet, but how would this work > if it's not coded in UTF-8? This is because I encountered a similar > problem when coding stuff for Facebook. Basically the system didn't > have UTF-8 encoding. As a result, I went by another person's > solution and converted the corresponding string into Unicode. This > is because the system can read Unicode, but not UTF-8. UTF-8 /is/ an encoding of Unicode. The one that system could read was some other, unspecified, encoding of Unicode. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | chad <cdalten@gmail.com> |
|---|---|
| Date | 2020-01-19 06:20 -0800 |
| Message-ID | <4d7bfef9-092b-4bc5-bf8d-e4d546fbd6ab@googlegroups.com> |
| In reply to | #149134 |
On Wednesday, January 15, 2020 at 7:36:06 AM UTC-8, Jorgen Grahn wrote: > On Wed, 2020-01-15, chad wrote: > > On Tuesday, January 14, 2020 at 9:33:01 AM UTC-8, Malcolm McLean wrote: > ... > >> Generally when we use the term "C string" we mean a nul-terminated string > >> with 8 bit characters, or coded in UTF-8. > ... > > Maybe this is too early in the morning yet, but how would this work > > if it's not coded in UTF-8? This is because I encountered a similar > > problem when coding stuff for Facebook. Basically the system didn't > > have UTF-8 encoding. As a result, I went by another person's > > solution and converted the corresponding string into Unicode. This > > is because the system can read Unicode, but not UTF-8. > > UTF-8 /is/ an encoding of Unicode. The one that system could read was > some other, unspecified, encoding of Unicode. > I thought about this for a minute. That makes sense in the context of the problem that I was attempting to solve at the time. And going off topic, I was reading in some other unspecified encoding of Unicode. Well, at least it was unspecified by Facebook, but is specified by a lot of other websites. I guess I should look into it. But I guess I was more concerned about getting the code to work correctly than looking for holy explanation on why it works the way it does.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-15 10:52 -0800 |
| Message-ID | <87imlcimc8.fsf@nosuchdomain.example.com> |
| In reply to | #149089 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Generally when we use the term "C string" we mean a nul-terminated string
> with 8 bit characters, or coded in UTF-8.
The C standard's actual definition of "string" has been quoted several
times in this thread.
> However the C language allows you to construct strings in memory which are
> not nul terminated.
No, the C language allows you to construct contiguous sequences of
characters which are not nul terminated. Such a sequence is by
definition not a string.
> These won't work as expected with printf() or any
> of the other C string handling functions. However you can write alternatives
> to these functions that operate on counted strings, or whatever
> alternative you have chosen.
printf() and other C string handling functions have undefined behavior
if passed a pointer that doesn't point to a 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]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-01-15 12:52 -0800 |
| Message-ID | <f6463b02-b0bb-493d-8db4-0f6ef5546abb@googlegroups.com> |
| In reply to | #149154 |
On Wednesday, 15 January 2020 18:52:33 UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > [...] > > Generally when we use the term "C string" we mean a nul-terminated string > > with 8 bit characters, or coded in UTF-8. > > The C standard's actual definition of "string" has been quoted several > times in this thread. > > > However the C language allows you to construct strings in memory which are > > not nul terminated. > > No, the C language allows you to construct contiguous sequences of > characters which are not nul terminated. Such a sequence is by > definition not a string. > The C standard does not legislate over the English language.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2020-01-15 20:56 +0000 |
| Message-ID | <qvnu91$ff4$1@news.xmission.com> |
| In reply to | #149159 |
In article <f6463b02-b0bb-493d-8db4-0f6ef5546abb@googlegroups.com>, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: >On Wednesday, 15 January 2020 18:52:33 UTC, Keith Thompson wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> [...] >> > Generally when we use the term "C string" we mean a nul-terminated string >> > with 8 bit characters, or coded in UTF-8. >> >> The C standard's actual definition of "string" has been quoted several >> times in this thread. >> >> > However the C language allows you to construct strings in memory which are >> > not nul terminated. >> >> No, the C language allows you to construct contiguous sequences of >> characters which are not nul terminated. Such a sequence is by >> definition not a string. >> >The C standard does not legislate over the English language. In Keith's world, it does. -- Those on the right constantly remind us that America is not a democracy; now they claim that Obama is a threat to democracy.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-01-16 02:17 +0000 |
| Message-ID | <87y2u8du0g.fsf@bsb.me.uk> |
| In reply to | #149159 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Wednesday, 15 January 2020 18:52:33 UTC, Keith Thompson wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> [...] >> > Generally when we use the term "C string" we mean a nul-terminated string >> > with 8 bit characters, or coded in UTF-8. >> >> The C standard's actual definition of "string" has been quoted several >> times in this thread. >> >> > However the C language allows you to construct strings in memory which are >> > not nul terminated. >> >> No, the C language allows you to construct contiguous sequences of >> characters which are not nul terminated. Such a sequence is by >> definition not a string. >> > The C standard does not legislate over the English language. That's exactly what it does. It's a quasi-legal document that gives very specific meanings to some English words and phrases -- mostly meanings that those words and phrases would not otherwise have. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web