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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-15 21:54 -0800 |
| Message-ID | <87tv4wgd4y.fsf@nosuchdomain.example.com> |
| 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.
Of course you know better. The C standard defines technical terms that
are used in the C standard. Some of those terms are English words like
"string". If you're going to talk about "strings" in the context of C,
we're going to assume that you mean "strings" as defined in 7.1.1.
Feel free to define and use a term like "Malcolm-strings" if you like.
--
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 | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-01-16 02:07 -0800 |
| Message-ID | <2aa601f0-5531-4cac-a423-2b37d1a830eb@googlegroups.com> |
| In reply to | #149177 |
W dniu czwartek, 16 stycznia 2020 06:54:16 UTC+1 użytkownik Keith Thompson napisał: > 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. > > Of course you know better. The C standard defines technical terms that > are used in the C standard. Some of those terms are English words like > "string". If you're going to talk about "strings" in the context of C, > we're going to assume that you mean "strings" as defined in 7.1.1. > > Feel free to define and use a term like "Malcolm-strings" if you like. > lul, think malcolm mclean is right (i eventually wanted to say that same thing to put that simple: in common sense string is generally 'strip' of characters "ala" is a string typical c-strings are ended by zero, example of typical c string char* txt = "ala ma kota";
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-01-16 02:45 -0800 |
| Message-ID | <e5c1b975-1f3f-455b-9707-92e460c0f8aa@googlegroups.com> |
| In reply to | #149178 |
On Thursday, 16 January 2020 10:07:19 UTC, fir wrote: > W dniu czwartek, 16 stycznia 2020 06:54:16 UTC+1 użytkownik Keith Thompson napisał: > > 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. > > > > Of course you know better. The C standard defines technical terms that > > are used in the C standard. Some of those terms are English words like > > "string". If you're going to talk about "strings" in the context of C, > > we're going to assume that you mean "strings" as defined in 7.1.1. > > > > Feel free to define and use a term like "Malcolm-strings" if you like. > > > > lul, think malcolm mclean is right (i eventually wanted to say that same thing > to put that simple: > > in common sense string is generally 'strip' of characters "ala" is a string > > typical c-strings are ended by zero, example of typical c string > > char* txt = "ala ma kota"; > Keith Thompson doesn't just say that "a string in the context of C is a nul-terminated array of chars", which would be correct unless, Bill Clinton like, we wish to quiblle over the defintion of "is". He says that "Such a sequence [of non-nul terminated chars] is by definition not a string". That's going too far. It quite likely does represent sequences of characters in a human-readable alphabet, so a "string" in normal computer parlance.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-01-16 08:21 -0700 |
| Message-ID | <1b36cftok3.fsf@pfeifferfamily.net> |
| In reply to | #149181 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Thursday, 16 January 2020 10:07:19 UTC, fir wrote: >> W dniu czwartek, 16 stycznia 2020 06:54:16 UTC+1 użytkownik Keith Thompson napisał: >> > 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. >> > >> > Of course you know better. The C standard defines technical terms that >> > are used in the C standard. Some of those terms are English words like >> > "string". If you're going to talk about "strings" in the context of C, >> > we're going to assume that you mean "strings" as defined in 7.1.1. >> > >> > Feel free to define and use a term like "Malcolm-strings" if you like. >> > >> >> lul, think malcolm mclean is right (i eventually wanted to say that same thing >> to put that simple: >> >> in common sense string is generally 'strip' of characters "ala" is a string >> >> typical c-strings are ended by zero, example of typical c string >> >> char* txt = "ala ma kota"; >> > Keith Thompson doesn't just say that "a string in the context of C is a > nul-terminated array of chars", which would be correct unless, Bill Clinton > like, we wish to quiblle over the defintion of "is". He says that "Such > a sequence [of non-nul terminated chars] is by definition not a string". > > That's going too far. It quite likely does represent sequences of characters > in a human-readable alphabet, so a "string" in normal computer parlance. If we're talking about strings in the context of their definition in the C language and library, and you suddenly start meaning the concept of strings in language theory (or physics, or flying kites) without clearly and explicitly saying you're now talking about something else then *everybody* is going to be confused. Even more, if someone else is clearly talking about strings in this context and you decide to interpret what they're saying in terms of improvised fishing line then *you're* going to be confused.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-01-16 08:03 -0800 |
| Message-ID | <52d6956d-991e-48a3-958b-abd1b2551f36@googlegroups.com> |
| In reply to | #149187 |
On Thursday, 16 January 2020 15:21:28 UTC, Joe Pfeiffer wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > Keith Thompson doesn't just say that "a string in the context of C is a > > nul-terminated array of chars", which would be correct unless, Bill Clinton > > like, we wish to quiblle over the defintion of "is". He says that "Such > > a sequence [of non-nul terminated chars] is by definition not a string". > > > > That's going too far. It quite likely does represent sequences of characters > > in a human-readable alphabet, so a "string" in normal computer parlance. > > If we're talking about strings in the context of their definition in the > C language and library, and you suddenly start meaning the concept of > strings in language theory (or physics, or flying kites) without clearly > and explicitly saying you're now talking about something else then > *everybody* is going to be confused. Even more, if someone else is > clearly talking about strings in this context and you decide to > interpret what they're saying in terms of improvised fishing line then > *you're* going to be confused. > It's not normally necessary to say "I was talking about strings in the context of the C programming language, now I am talking about strings of sausages". One moves fluidly from topic to topic. There's a science fiction book caled "The Prayer Machine" by Christopher Hodder Williams. The hero travels to the future. As he adventures in the future world, the author gradually introduces terms like "plastic cancer" and "Ponem", which refer to the new environment. Plastic cancer is a new type of cancer caused by genetically engineering organisms to bond with polymers, and a "Ponem" is a "point of no effective mass", a sort of advanced particle accelerator type physics intrument. Then there's a speech by the hero larded with such terms, which we as readers understand without glossing, along the lines of "I'm at the Ponem. No, I don't have plastic cancer" etc. Later on, the speech is relayed to the present, where it is dismissed by the psychiatrists treating the hero as meaningless psychotic ravings. That's a feature of natural language. We don't explicitly define terms, except in artifical settings like standards documents. Terms acquire meaning from how we use them.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2020-01-16 09:06 -0800 |
| Message-ID | <ada7091b-3f00-4b56-9f7f-bbebc7f7de34@googlegroups.com> |
| In reply to | #149181 |
On Thursday, January 16, 2020 at 4:45:46 AM UTC-6, Malcolm McLean wrote: > On Thursday, 16 January 2020 10:07:19 UTC, fir wrote: > > W dniu czwartek, 16 stycznia 2020 06:54:16 UTC+1 użytkownik Keith Thompson napisał: > > > 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. > > > > > > Of course you know better. The C standard defines technical terms that > > > are used in the C standard. Some of those terms are English words like > > > "string". If you're going to talk about "strings" in the context of C, > > > we're going to assume that you mean "strings" as defined in 7.1.1. > > > > > > Feel free to define and use a term like "Malcolm-strings" if you like. > > > > > > > lul, think malcolm mclean is right (i eventually wanted to say that same thing > > to put that simple: > > > > in common sense string is generally 'strip' of characters "ala" is a string > > > > typical c-strings are ended by zero, example of typical c string > > > > char* txt = "ala ma kota"; > > > Keith Thompson doesn't just say that "a string in the context of C is a > nul-terminated array of chars", which would be correct unless, Bill Clinton > like, we wish to quiblle over the defintion of "is". He says that "Such > a sequence [of non-nul terminated chars] is by definition not a string". > > That's going too far. It quite likely does represent sequences of characters > in a human-readable alphabet, so a "string" in normal computer parlance. This is a C language newsgroup, and the question centers on what is considered a string IN THE C LANGUAGE. The context is obvious and shouldn't require any additional qualification. Obviously Keith's statement is in regard to C, not general English usage. That's a level of meaningless pedantry that would make James May blush. Stop it.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-16 11:29 -0800 |
| Message-ID | <cd04b441-4027-42d9-869e-fc0cb7865c7d@googlegroups.com> |
| In reply to | #149181 |
Malcolm McLean wrote: > Keith Thompson doesn't just say that "a string in the context of C is a > nul-terminated array of chars", which would be correct unless, Bill Clinton > like, we wish to quiblle over the defintion of "is". He says that "Such > a sequence [of non-nul terminated chars] is by definition not a string". This is comp.lang.c, and this is the middle of a discussion about C. For either of those reasons, "in the context of C" doesn't need to be explicitly stated, it's the default. In this context, it's the person who uses a term with a meaning that's different from the one specified by the C Standard who has an obligation to warn people about that fact.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-01-16 02:01 +0000 |
| Message-ID | <874kwwf9cs.fsf@bsb.me.uk> |
| In reply to | #149154 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > 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. To be a bit picky... Given char a[3] = "foo", b[3] = "bar"; // neither is null-terminated. a call like strncmp(a, b, sizeof a) is not undefined even though the standard calls strncmp a string handling function. The description takes care to talk about character arrays, though. Calls like strcmp(a, b) strchr(a, 'o') strspn(b, "abc") would, from an operational point of view, seem to be well-defined as the presence of a null is not obviously needed, but the function descriptions say the pointers should point to strings. Are they undefined calls? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-15 23:02 -0500 |
| Message-ID | <qvon97$jkd$1@dont-email.me> |
| In reply to | #149165 |
On 1/15/20 9:01 PM, Ben Bacarisse wrote: ... > To be a bit picky... Given > > char a[3] = "foo", b[3] = "bar"; // neither is null-terminated. > > a call like > > strncmp(a, b, sizeof a) > > is not undefined even though the standard calls strncmp a string > handling function. The description takes care to talk about character > arrays, though. > > Calls like > > strcmp(a, b) > strchr(a, 'o') > strspn(b, "abc") > > would, from an operational point of view, seem to be well-defined as the > presence of a null is not obviously needed, but the function > descriptions say the pointers should point to strings. Are they > undefined calls? There are simple, obvious ways to implement those functions which have no reason to read beyond the end of either array. However, because those functions are specified as taking arguments that point to strings, a conforming implementation could implement those functions in a less obvious way that could produce trouble if they're not actually strings. For instance, they could call strlen() to determine the lengths of each input string, and use different algorithms for short strings than for long ones. I'm not saying that this is likely, only that it's permitted.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-16 11:15 +0100 |
| Message-ID | <qvpd4f$pis$1@dont-email.me> |
| In reply to | #149165 |
On 16/01/2020 03:01, Ben Bacarisse wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> 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. > > To be a bit picky... Given > > char a[3] = "foo", b[3] = "bar"; // neither is null-terminated. > > a call like > > strncmp(a, b, sizeof a) > > is not undefined even though the standard calls strncmp a string > handling function. The description takes care to talk about character > arrays, though. > > Calls like > > strcmp(a, b) > strchr(a, 'o') > strspn(b, "abc") > > would, from an operational point of view, seem to be well-defined as the > presence of a null is not obviously needed, but the function > descriptions say the pointers should point to strings. Are they > undefined calls? > What about strcmp(a, a); or: char a[3] = "foo", b[3] = "foo"; strcmp(a, b);
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-01-16 13:07 +0000 |
| Message-ID | <875zhbeei0.fsf@bsb.me.uk> |
| In reply to | #149179 |
David Brown <david.brown@hesbynett.no> writes: > On 16/01/2020 03:01, Ben Bacarisse wrote: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> 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. >> >> To be a bit picky... Given >> >> char a[3] = "foo", b[3] = "bar"; // neither is null-terminated. >> >> a call like >> >> strncmp(a, b, sizeof a) >> >> is not undefined even though the standard calls strncmp a string >> handling function. The description takes care to talk about character >> arrays, though. >> >> Calls like >> >> strcmp(a, b) >> strchr(a, 'o') >> strspn(b, "abc") >> >> would, from an operational point of view, seem to be well-defined as the >> presence of a null is not obviously needed, but the function >> descriptions say the pointers should point to strings. Are they >> undefined calls? >> > > What about > > strcmp(a, a); > > or: > > char a[3] = "foo", b[3] = "foo"; > > strcmp(a, b); Since these are not in doubt, your point is, presumably, that the others can't be in doubt either. Nothing in the wording distinguishes between the "operationally safe" calls and the others. Given that we have memcmp and memchr, there's rarely any temptation for making dodgy calls. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2020-01-17 18:43 +0100 |
| Message-ID | <qvsrol$10f5$1@gioia.aioe.org> |
| In reply to | #149165 |
On 1/16/2020 3:01 AM, Ben Bacarisse wrote: >> printf() and other C string handling functions have undefined behavior >> if passed a pointer that doesn't point to a string. > To be a bit picky... Given > > char a[3] = "foo", b[3] = "bar"; // neither is null-terminated. > > a call like > > strncmp(a, b, sizeof a) > > is not undefined even though the standard calls strncmp a string > handling function. The description takes care to talk about character > arrays, though. > > Calls like > > strcmp(a, b) > strchr(a, 'o') > strspn(b, "abc") > > would, from an operational point of view, seem to be well-defined as the > presence of a null is not obviously needed, but the function > descriptions say the pointers should point to strings. Are they > undefined calls? Since the standard requires these functions to be called with (null terminated) strings, I would say that these are formally UB calls, even if any sane implementation will give the correct result (which also falls within the category of UB). It might seem even more disturbing considering that if a and b are static strings an optimizing compiler is likely to optimize out the call itself.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-21 04:00 -0800 |
| Message-ID | <865zh5j9yq.fsf@linuxsc.com> |
| In reply to | #149226 |
Manfred <noname@add.invalid> writes: > On 1/16/2020 3:01 AM, Ben Bacarisse wrote: > >>> printf() and other C string handling functions have undefined behavior >>> if passed a pointer that doesn't point to a string. >> >> To be a bit picky... Given >> >> char a[3] = "foo", b[3] = "bar"; // neither is null-terminated. >> >> a call like >> >> strncmp(a, b, sizeof a) >> is not undefined even though the standard calls strncmp a string >> handling function. The description takes care to talk about character >> arrays, though. >> >> Calls like >> >> strcmp(a, b) >> strchr(a, 'o') >> strspn(b, "abc") >> >> would, from an operational point of view, seem to be well-defined as the >> presence of a null is not obviously needed, but the function >> descriptions say the pointers should point to strings. Are they >> undefined calls? > > Since the standard requires these functions to be called with (null > terminated) strings, I would say that these are formally UB calls, > even if any sane implementation will give the correct result (which > also falls within the category of UB). The phrasing there seems a bit off. "Undefined behavior" is a semantic specification. The result -- or any result -- of a computation cannot be "undefined behavior". What I think you mean is that giving an expected result is allowed when the construct in question is specified as having undefined behavior.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-21 05:00 -0800 |
| Message-ID | <84545ff5-560b-41ef-a060-043843e59454@googlegroups.com> |
| In reply to | #149226 |
On Friday, January 17, 2020 at 12:43:58 PM UTC-5, Manfred wrote: ... > Since the standard requires these functions to be called with (null > terminated) strings, I would say that these are formally UB calls, even > if any sane implementation will give the correct result (which also > falls within the category of UB). I agree that any sane implementation will give the correct result; so will any insane implementations, and even non-conforming implementations. That's because, when the behavior is undefined, the standard imposes no requirements. It is therefore impossible to violate the standard's requirements, so any behavior is correct. I think that what you mean is that any sane implementation will give the behavior that many people incorrectly assume is the only correct behavior. You might be right about that. The most obvious implementation of those functions won't run into any problems. However, I wouldn't recommend counting on it. Implementations are allowed to optimize code in ways that depend upon the code having defined behavior, and those optimizations can produce quite surprising results when used on code that violates that assumption.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-01-14 12:36 -0700 |
| Message-ID | <1bimldu8yl.fsf@pfeifferfamily.net> |
| In reply to | #149088 |
T <T@invalid.invalid> writes: > Hi All, > > Had this conversatio with someone over on the > Raku mailing list: > >>> By the way, "C String" REQUIRES a nul at the end: >>> an error in the NativeCall documentation. > >> No, it does not. And even if it did, it should better go to the C, not Raku, documentation > > Would someone correct me if a C String actually does > not require a nul to terminate itself? > > If I am correct, would someone give me the chapter and > verse in the ISO that states this. (The guy I am > conversing with will ot take a third party definition.) The catch here is that C doesn't actually have strings, except for string literals in the source code. Strings in programs are really expectations on the part of the standard library, not part of the language itself. The definition of the standard C library contains the following: "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." This appears in the C draft standard ISO/IEC 9899:201x (I expect it is unchanged in the current, adopted standard but this is what I've got).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-14 12:05 -0800 |
| Message-ID | <878sm9kdm7.fsf@nosuchdomain.example.com> |
| In reply to | #149096 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
[...]
> The catch here is that C doesn't actually have strings, except for
> string literals in the source code. Strings in programs are really
> expectations on the part of the standard library, not part of the
> language itself.
C certainly does have strings, and you quoted the definition
yourself.
Strings exist at run time. A lot of standard library functions
require pointers to strings, but it's perfectly possible to use
strings in a C program independently of the standard library.
I suspect there's some true statement behind your statement that
"C doesn't actually have strings", but I honestly don't know what
it is. Can you clarify?
[...]
--
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 | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-01-14 13:54 -0700 |
| Message-ID | <1bblr5u5c4.fsf@pfeifferfamily.net> |
| In reply to | #149100 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: > [...] >> The catch here is that C doesn't actually have strings, except for >> string literals in the source code. Strings in programs are really >> expectations on the part of the standard library, not part of the >> language itself. > > C certainly does have strings, and you quoted the definition > yourself. > > Strings exist at run time. A lot of standard library functions > require pointers to strings, but it's perfectly possible to use > strings in a C program independently of the standard library. > > I suspect there's some true statement behind your statement that > "C doesn't actually have strings", but I honestly don't know what > it is. Can you clarify? The spec separates the definition of the language itself (everything before chapter 7) from the standard library (chapter 7). Unless I missed it, chapters 1-6 only mention strings in the context of string literals. The language (as distinguished from the library) has no builtin string data type, no builtin string operators such as concatenation or taking a substring, etc. The only place I know of that the language itself supports null-terminated strings is by adding a null to a string literal when initializing a pointer or a long-enough array. In that sense, strings are in the library but not the language.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-14 15:03 -0800 |
| Message-ID | <375eeb8d-76b1-47a3-a952-eebefdac5cdd@googlegroups.com> |
| In reply to | #149101 |
It is perfectly true that C doesn't have a string data type. It does, however, have a string data format. C is not just the C language, it is also the C standard library. You can't have a fully conforming implementation of C without both. Many of the C standard library routines have their behavior defined in term of that data format, and the C language itself has two features that make it easy to generate data in that format: 1. When a string literal is used to initialize a array of character type with an unspecified length, or a length large enough to hold a terminating nul character, it results in the creation of data in that format. 2. When used in most other contexts (except as the operand of & or sizeof), a string literal causes the creation of an unnamed character array containing data in that format, and has a value that points at the first element of that array.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-01-15 04:55 -0800 |
| Message-ID | <10d6d33c-164f-4dab-9800-b796ed82c436@googlegroups.com> |
| In reply to | #149105 |
On Tuesday, January 14, 2020 at 8:03:46 PM UTC-3, James Kuyper wrote:
> It is perfectly true that C doesn't have a string data type. It does,
> however, have a string data format. C is not just the C language, it is
> also the C standard library. You can't have a fully conforming
> implementation of C without both.
The close relationship with pointers and arrays makes
the idea of string data type int C very difficult.
I used to have a typedef for string. But now I think it
is a bad idea because it is inconsistent.
One inconsistency is caused by const.
typedef char* string;
void F(const string s) {
s[1] = '1';
}
int main() {
char s1[] = "test";
const string s = s1;
F(s);
}
In this sample, the function F is able to change the
string s with no warnings. Because string type does
not represents the data.
Sometimes we have pointer that works like an
"c++ iterator". It can be a char * p and the content
can be a string zero terminated but this does not mean
I want to use the p as string. I may use it as
a 'position mark' or just a pointer to char.
This is what I means by this close relationship between
pointers arrays and strings.
[toc] | [prev] | [next] | [standalone]
| From | Guillaume <message@bottle.org> |
|---|---|
| Date | 2020-01-15 20:49 +0100 |
| Message-ID | <qvnqbh$6lr$1@gioia.aioe.org> |
| In reply to | #149123 |
Le 15/01/2020 à 13:55, Thiago Adams a écrit :
> On Tuesday, January 14, 2020 at 8:03:46 PM UTC-3, James Kuyper wrote:
> I used to have a typedef for string. But now I think it
> is a bad idea because it is inconsistent.
>
> One inconsistency is caused by const.
Yes, this is a common pitfall, and the reason why some guidelines
strongly advise against defining pointer types (with typedef.)
https://wiki.sei.cmu.edu/confluence/display/c/DCL05-C.+Use+typedefs+of+non-pointer+types+only
"Hiding" that some type is actually a pointer is a bad idea IMO - not
just for the "const" pitfall.
A better way of defining a "string" type, if you had to do it, would be
the following IMO:
typedef
{
char *string;
size_t length; // optional, could be an addition to make some
string operations more efficient
} String_t;
typedef
{
const char *string;
const size_t length; // optional, could be an addition to make some
string operations more efficient
} ConstString_t;
Yep you'd need two types for really having "constant" strings. But it
would be easy to write functions to go from one to the other when needed.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web