Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63008 > unrolled thread
| Started by | bilsch01 <king621@comcast.net> |
|---|---|
| First post | 2015-06-06 04:58 -0700 |
| Last post | 2015-07-26 01:00 +0200 |
| Articles | 20 on this page of 112 — 19 participants |
Back to article view | Back to comp.lang.c
counting bytes bilsch01 <king621@comcast.net> - 2015-06-06 04:58 -0700
Re: counting bytes Bartc <bc@freeuk.com> - 2015-06-06 13:05 +0100
Re: counting bytes bilsch01 <king621@comcast.net> - 2015-06-06 05:24 -0700
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-06 05:41 -0700
Re: counting bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-06 14:00 +0100
Re: counting bytes Bartc <bc@freeuk.com> - 2015-06-06 13:52 +0100
Re: counting bytes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-06-06 10:27 -0400
Re: counting bytes jt@toerring.de (Jens Thoms Toerring) - 2015-06-06 22:31 +0000
THANKS EVERYBODY FOR THE INFO bilsch01 <king621@comcast.net> - 2015-06-06 23:35 -0700
Re: THANKS EVERYBODY FOR THE INFO Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-07 10:08 +0100
Re: THANKS EVERYBODY FOR THE INFO Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-07 09:22 -0700
Re: THANKS EVERYBODY FOR THE INFO Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-07 18:07 +0100
Re: THANKS EVERYBODY FOR THE INFO Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-08 04:03 -0700
Re: THANKS EVERYBODY FOR THE INFO Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:12 -0700
Re: THANKS EVERYBODY FOR THE INFO Keith Thompson <kst-u@mib.org> - 2015-06-07 08:01 -0700
Re: counting bytes gordonb.3gcai@burditt.org (Gordon Burditt) - 2015-06-07 05:02 -0500
Re: counting bytes David Brown <david.brown@hesbynett.no> - 2015-06-07 15:32 +0200
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-06-07 12:48 -0700
Re: counting bytes David Brown <david.brown@hesbynett.no> - 2015-06-07 23:05 +0200
Re: counting bytes Richard Heathfield <rjh@cpax.org.uk> - 2015-06-07 22:17 +0100
Re: counting bytes David Brown <david.brown@hesbynett.no> - 2015-06-07 23:49 +0200
Re: counting bytes Richard Heathfield <rjh@cpax.org.uk> - 2015-06-07 23:37 +0100
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:25 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:21 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-11 13:54 -0500
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 06:33 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-20 09:51 -0500
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 09:49 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-24 12:26 -0500
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 11:16 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-30 23:15 -0500
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:07 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-02 14:31 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-09 05:31 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-09 17:09 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 09:58 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-09-05 19:29 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 14:38 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-09-06 17:46 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 23:50 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-09-06 22:00 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 23:24 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-24 20:03 -0400
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-24 22:13 -0500
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 02:22 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-25 11:39 -0500
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 09:48 -0700
Re: counting bytes Martin Shobe <martin.shobe@yahoo.com> - 2015-07-25 14:04 -0500
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 14:22 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-25 11:07 -0400
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-25 12:43 -0400
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-25 13:32 -0400
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-25 20:14 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-25 17:24 -0400
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 14:42 -0700
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-25 23:02 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-25 19:17 -0400
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 16:37 -0700
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-26 06:10 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-26 08:31 -0400
Re: counting bytes Bartc <bc@freeuk.com> - 2015-07-30 21:32 +0100
Re: counting bytes raltbos@xs4all.nl (Richard Bos) - 2015-07-31 13:25 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-31 11:31 -0400
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-31 11:30 -0700
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-31 14:29 -0400
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-31 12:14 -0700
Re: counting bytes David Kleinecke <dkleinecke@gmail.com> - 2015-07-31 17:39 -0700
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-31 23:32 -0400
Re: counting bytes David Kleinecke <dkleinecke@gmail.com> - 2015-08-01 16:41 -0700
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-08-01 20:23 -0400
Re: counting bytes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-31 11:01 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-25 19:42 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:16 -0700
Re: counting bytes Bartc <bc@freeuk.com> - 2015-07-30 22:04 +0100
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:10 -0700
Re: counting bytes David Kleinecke <dkleinecke@gmail.com> - 2015-07-25 19:10 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-25 22:16 -0400
Re: counting bytes David Kleinecke <dkleinecke@gmail.com> - 2015-07-25 19:46 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 11:52 -0700
Re: counting bytes raltbos@xs4all.nl (Richard Bos) - 2015-07-31 08:51 +0000
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:19 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-01 09:39 -0400
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-08-01 13:06 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-01 20:43 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 06:52 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-02 15:14 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-09 07:54 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-08-09 16:43 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 10:48 -0700
Re: counting bytes Richard Damon <Richard@Damon-Family.org> - 2015-07-11 17:50 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 06:36 -0700
Re: counting bytes raltbos@xs4all.nl (Richard Bos) - 2015-07-20 15:14 +0000
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 09:38 -0700
Re: counting bytes raltbos@xs4all.nl (Richard Bos) - 2015-07-25 19:12 +0000
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:18 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-11 17:03 -0700
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 00:15 +0000
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-11 17:42 -0700
Re: counting bytes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 02:46 +0000
Re: counting bytes James Kuyper <jameskuyper@verizon.net> - 2015-07-12 12:33 -0400
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 06:48 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-20 11:18 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 09:58 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-24 11:14 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 11:02 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-07-30 13:10 -0700
Re: counting bytes Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-01 10:53 -0700
Re: counting bytes Keith Thompson <kst-u@mib.org> - 2015-06-07 14:46 -0700
Re: counting bytes David Brown <david.brown@hesbynett.no> - 2015-06-08 09:05 +0200
Re: counting bytes Siri Cruz <chine.bleu@yahoo.com> - 2015-06-06 05:06 -0700
Re: counting bytes bartekltg <bartekltg@gmail.com> - 2015-07-26 00:58 +0200
Re: counting bytes bartekltg <bartekltg@gmail.com> - 2015-07-26 01:00 +0200
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-30 21:32 +0100 |
| Message-ID | <mpe1hs$pf6$1@dont-email.me> |
| In reply to | #66372 |
On 26/07/2015 00:02, glen herrmannsfeldt wrote: > James Kuyper <jameskuyper@verizon.net> wrote: > > (snip, I wrote) >>> This problem will become more common if systems move to a 16 bit >>> unicode char, but want to keep an 8 bit type. > >> Why not just use char16_t (new in C2011) for 16-bit unicode, and leave >> char unchanged? I mean - that's what char16_t is FOR. If you didn't want >> to have any 8-bit type, I could understand making char a 16-bit type, >> with char16_t a typedef for 'unsigned char'. However, if you want to >> keep an 8-bit type, why not call it 'char'? > > We have names for many prejudices, but maybe not yet one for > people who think 8 bits will always be enough. Why shouldn't it? For text, 7-bit ASCII will cover a huge chunk of requirements, and 8-bit UTF-8 will cover the rest. > > OK, how about bitism. > > Consider a host system that only allow for 16 bit character data. > > Yes you can keep char as the eight bit data type, but you get stuck > very quickly. > > It would be much nicer to have 16 bit char, and 8 bit uint8_t, You can build a 16-bit char type on top of 8-bit char more easily than the other way around. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-07-31 13:25 +0000 |
| Message-ID | <55bb7710.17217812@news.xs4all.nl> |
| In reply to | #66360 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 07/25/2015 04:14 PM, glen herrmannsfeldt wrote: > ... > > This problem will become more common if systems move to a 16 bit > > unicode char, but want to keep an 8 bit type. > > Why not just use char16_t (new in C2011) Because it is a bloody awful idea, yet another sop to Microsoft and their intentionally half-hearted approach to internationalisation and portability. Richard
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-31 11:31 -0400 |
| Message-ID | <55BB94DC.5030608@verizon.net> |
| In reply to | #66604 |
On 07/31/2015 09:25 AM, Richard Bos wrote: > James Kuyper <jameskuyper@verizon.net> wrote: > >> On 07/25/2015 04:14 PM, glen herrmannsfeldt wrote: >> ... >>> This problem will become more common if systems move to a 16 bit >>> unicode char, but want to keep an 8 bit type. >> >> Why not just use char16_t (new in C2011) > > Because it is a bloody awful idea, yet another sop to Microsoft and > their intentionally half-hearted approach to internationalisation and > portability. He's already decided he wants a 16 bit unicode representation. As I understand it, UCS-2 was the first such representation, with UTF-16 the more recent and (in many contexts) the preferred one. As far I know, there aren't any others. Having made that decision, what's wrong with using char16_t to store those encodings? If you're criticizing his decision, rather than my suggestion, then you should have responded to his message, rather than mine. Let me clarify that I don't see char16_t as having any significant advantage over uint_least16_t, which is required to be the same type; the different typedef merely clarifies the intended use of the data. So when I was referring to char16_t, I was really thinking terms of the new language features that are tied to char16_t, rather than the typedef itself. Prior to C2011, there was no standardized way of dealing with UTF-16 encodings. In C2011, if an implementation pre#defines __STDC_UTF_16__, character constants and string literals that use the 'u' prefix are encoded using UTF-16, and mbrtoc16() and cr16rtomb() interpret their inputs as having been encoded using UTF-16. While Microsoft may be the biggest user of UTF-16, UTF-16 is not Microsoft-specific <https://en.wikipedia.org/wiki/UTF-16#Usage>. In fact, I've been informed, as recently as February 2014, that there's still a lot of Microsoft code that treats 16-bit text as UCS-2 (which is also not Microsoft-specific) rather than UTF-16.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-31 11:30 -0700 |
| Message-ID | <lnh9okkwms.fsf@kst-u.example.com> |
| In reply to | #66606 |
James Kuyper <jameskuyper@verizon.net> writes:
[...]
> Prior to C2011, there was no standardized way of dealing with UTF-16
> encodings. In C2011, if an implementation pre#defines __STDC_UTF_16__,
> character constants and string literals that use the 'u' prefix are
> encoded using UTF-16, and mbrtoc16() and cr16rtomb() interpret their
> inputs as having been encoded using UTF-16.
That's not quite correct. The meaning of the 'u' prefix is not tied to
any predefined macro setting.
L"foo" is of type wchar_t[].
u"foo" is of type char16_t[].
U"foo" is of type char32_t[].
u8"foo" is of type char[] and is encoded in UTF-8.
__STDC_UTF_16__ indicates that values of type char16_t are UTF-16
encoded; otherwise the encoding is implementation-defined.
__STDC_UTF_32__ indicates that values of type char32_t are UTF-32
encoded.
Both could plausibly be defined as 1. I think they affect the
behavior of functions declared in <uchar.h>.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-31 14:29 -0400 |
| Message-ID | <55BBBE70.8090907@verizon.net> |
| In reply to | #66608 |
On 07/31/2015 02:30 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@verizon.net> writes: > [...] >> Prior to C2011, there was no standardized way of dealing with UTF-16 >> encodings. In C2011, if an implementation pre#defines __STDC_UTF_16__, >> character constants and string literals that use the 'u' prefix are >> encoded using UTF-16, and mbrtoc16() and cr16rtomb() interpret their >> inputs as having been encoded using UTF-16. > > That's not quite correct. The meaning of the 'u' prefix is not tied to > any predefined macro setting. > > L"foo" is of type wchar_t[]. > u"foo" is of type char16_t[]. > U"foo" is of type char32_t[]. > u8"foo" is of type char[] and is encoded in UTF-8. > > __STDC_UTF_16__ indicates that values of type char16_t are UTF-16 > encoded; otherwise the encoding is implementation-defined. u"foo"[0] is a value of type char16_t. I don't understand what __STDC_UTF_16__ means if it doesn't apply to that value. > __STDC_UTF_32__ indicates that values of type char32_t are UTF-32 > encoded. > > Both could plausibly be defined as 1. I think they affect the > behavior of functions declared in <uchar.h>. If you believe that it applies to mbrtoc16(), which is declared in that header, then the following citations prove that it also applies to character constants and string literals defined with a 'u' prefix: "The value of a wide character constant containing a single multibyte character that maps to a single member of the extended execution character set is the wide character corresponding to that multibyte character, as defined by the mbtowc, mbrtoc16, or mbrtoc32 function as appropriate for its type, with an implementation-defined current locale." 6.4.4.4p11 "For wide string literals prefixed by the letter u or U, the array elements have type char16_t or char32_t, respectively, and are initialized with the sequence of wide characters corresponding to the multibyte character sequence, as defined by successive calls to the mbrtoc16, or mbrtoc32 function as appropriate for its type, with an implementation-defined current locale." 6.4.5p6 I don't like this "implementation-defined current locale". There should also be a way for a program to find out which locale was used.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-31 12:14 -0700 |
| Message-ID | <lnd1z8kuma.fsf@kst-u.example.com> |
| In reply to | #66613 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 07/31/2015 02:30 PM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>> [...]
>>> Prior to C2011, there was no standardized way of dealing with UTF-16
>>> encodings. In C2011, if an implementation pre#defines __STDC_UTF_16__,
>>> character constants and string literals that use the 'u' prefix are
>>> encoded using UTF-16, and mbrtoc16() and cr16rtomb() interpret their
>>> inputs as having been encoded using UTF-16.
>>
>> That's not quite correct. The meaning of the 'u' prefix is not tied to
>> any predefined macro setting.
>>
>> L"foo" is of type wchar_t[].
>> u"foo" is of type char16_t[].
>> U"foo" is of type char32_t[].
>> u8"foo" is of type char[] and is encoded in UTF-8.
>>
>> __STDC_UTF_16__ indicates that values of type char16_t are UTF-16
>> encoded; otherwise the encoding is implementation-defined.
>
> u"foo"[0] is a value of type char16_t. I don't understand what
> __STDC_UTF_16__ means if it doesn't apply to that value.
[...]
Please ignore my previous message. I somehow managed to misread your
message as saying that __STDC_UTF_16__ affects the *type* of u"foo".
Clearly it doesn't, and clearly you didn't say so.
Sorry about the noise.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-31 17:39 -0700 |
| Message-ID | <c54daa10-05c6-4572-846c-0be34bedf623@googlegroups.com> |
| In reply to | #66615 |
On Friday, July 31, 2015 at 11:40:02 AM UTC-7, Keith Thompson wrote: > James Kuyper <jameskuyper@verizon.net> writes: > > On 07/31/2015 02:30 PM, Keith Thompson wrote: > >> James Kuyper <jameskuyper@verizon.net> writes: > >> [...] > >>> Prior to C2011, there was no standardized way of dealing with UTF-16 > >>> encodings. In C2011, if an implementation pre#defines __STDC_UTF_16__, > >>> character constants and string literals that use the 'u' prefix are > >>> encoded using UTF-16, and mbrtoc16() and cr16rtomb() interpret their > >>> inputs as having been encoded using UTF-16. > >> > >> That's not quite correct. The meaning of the 'u' prefix is not tied to > >> any predefined macro setting. > >> > >> L"foo" is of type wchar_t[]. > >> u"foo" is of type char16_t[]. > >> U"foo" is of type char32_t[]. > >> u8"foo" is of type char[] and is encoded in UTF-8. > >> > >> __STDC_UTF_16__ indicates that values of type char16_t are UTF-16 > >> encoded; otherwise the encoding is implementation-defined. > > > > u"foo"[0] is a value of type char16_t. I don't understand what > > __STDC_UTF_16__ means if it doesn't apply to that value. > [...] There are two cases to consider. There are languages (Chinese is most obvious) where more than 256 characters are needed. But almost all other languages use less than 256 (assuming some smart ligature and compound work). We could encode in two steps - it might not be Unicode but that is not proven - call them a bank and a font. The bank picks out a font representation and font a character glyph. The two bytes of UTF-16 are obvious. Stdio would need to be aware. The simplest approach would be to add a font selection function that printf responds to (but not fprint or sprint). It would be time to recognize that printf needs better control over what is displayed. Chinese (and et al if any) needs its own specialized approach.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-31 23:32 -0400 |
| Message-ID | <mphei8$b25$1@dont-email.me> |
| In reply to | #66625 |
On 07/31/2015 08:39 PM, David Kleinecke wrote: > On Friday, July 31, 2015 at 11:40:02 AM UTC-7, Keith Thompson wrote: >> James Kuyper <jameskuyper@verizon.net> writes: >>> On 07/31/2015 02:30 PM, Keith Thompson wrote: >>>> James Kuyper <jameskuyper@verizon.net> writes: >>>> [...] >>>>> Prior to C2011, there was no standardized way of dealing with UTF-16 >>>>> encodings. In C2011, if an implementation pre#defines __STDC_UTF_16__, >>>>> character constants and string literals that use the 'u' prefix are >>>>> encoded using UTF-16, and mbrtoc16() and cr16rtomb() interpret their >>>>> inputs as having been encoded using UTF-16. >>>> >>>> That's not quite correct. The meaning of the 'u' prefix is not tied to >>>> any predefined macro setting. >>>> >>>> L"foo" is of type wchar_t[]. >>>> u"foo" is of type char16_t[]. >>>> U"foo" is of type char32_t[]. >>>> u8"foo" is of type char[] and is encoded in UTF-8. >>>> >>>> __STDC_UTF_16__ indicates that values of type char16_t are UTF-16 >>>> encoded; otherwise the encoding is implementation-defined. >>> >>> u"foo"[0] is a value of type char16_t. I don't understand what >>> __STDC_UTF_16__ means if it doesn't apply to that value. >> [...] > > There are two cases to consider. There are languages (Chinese is most > obvious) where more than 256 characters are needed. Any encoding which needs to be able to simultaneously a sufficiently wide variety of languages runs into the same problem. I don't think 256 is sufficient to even cover all of the European variations on the Latin alphabet. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-01 16:41 -0700 |
| Message-ID | <d662f72e-32da-4091-900f-03611b278fad@googlegroups.com> |
| In reply to | #66632 |
On Friday, July 31, 2015 at 8:33:04 PM UTC-7, James Kuyper wrote: > On 07/31/2015 08:39 PM, David Kleinecke wrote: > > On Friday, July 31, 2015 at 11:40:02 AM UTC-7, Keith Thompson wrote: > >> James Kuyper <jameskuyper@verizon.net> writes: > >>> On 07/31/2015 02:30 PM, Keith Thompson wrote: > >>>> James Kuyper <jameskuyper@verizon.net> writes: > >>>> [...] > >>>>> Prior to C2011, there was no standardized way of dealing with UTF-16 > >>>>> encodings. In C2011, if an implementation pre#defines __STDC_UTF_16__, > >>>>> character constants and string literals that use the 'u' prefix are > >>>>> encoded using UTF-16, and mbrtoc16() and cr16rtomb() interpret their > >>>>> inputs as having been encoded using UTF-16. > >>>> > >>>> That's not quite correct. The meaning of the 'u' prefix is not tied to > >>>> any predefined macro setting. > >>>> > >>>> L"foo" is of type wchar_t[]. > >>>> u"foo" is of type char16_t[]. > >>>> U"foo" is of type char32_t[]. > >>>> u8"foo" is of type char[] and is encoded in UTF-8. > >>>> > >>>> __STDC_UTF_16__ indicates that values of type char16_t are UTF-16 > >>>> encoded; otherwise the encoding is implementation-defined. > >>> > >>> u"foo"[0] is a value of type char16_t. I don't understand what > >>> __STDC_UTF_16__ means if it doesn't apply to that value. > >> [...] > > > > There are two cases to consider. There are languages (Chinese is most > > obvious) where more than 256 characters are needed. > > Any encoding which needs to be able to simultaneously a sufficiently > wide variety of languages runs into the same problem. I don't think 256 > is sufficient to even cover all of the European variations on the Latin > alphabet. You stopped reading at this point.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-01 20:23 -0400 |
| Message-ID | <55BD6313.7030904@verizon.net> |
| In reply to | #66668 |
On 08/01/2015 07:41 PM, David Kleinecke wrote: > On Friday, July 31, 2015 at 8:33:04 PM UTC-7, James Kuyper wrote: >> On 07/31/2015 08:39 PM, David Kleinecke wrote: ... >>> There are two cases to consider. There are languages (Chinese is most >>> obvious) where more than 256 characters are needed. >> >> Any encoding which needs to be able to simultaneously a sufficiently >> wide variety of languages runs into the same problem. I don't think 256 >> is sufficient to even cover all of the European variations on the Latin >> alphabet. > > You stopped reading at this point. No, I continued reading, I just stopped comprehending - but if the part I didn't respond to is relevant to the response I did make, than I understood it even less well than I thought I did - which seems entirely possible.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-31 11:01 -0700 |
| Message-ID | <57fdd54a-6e74-4db6-bf0d-78a9ce3a6ab3@googlegroups.com> |
| In reply to | #66604 |
On Friday, July 31, 2015 at 2:26:11 PM UTC+1, Richard Bos wrote: > James Kuyper <jameskuyper@verizon.net> wrote: > > > > > This problem will become more common if systems move to > > > a 16 bit unicode char, but want to keep an 8 bit type. > > > > Why not just use char16_t (new in C2011) > > Because it is a bloody awful idea, yet another sop to Microsoft > and their intentionally half-hearted approach to > internationalisation and portability. > Naively, the answer to internationalisation is to use a wider character type. So that's what MS did. They've got plenty of non-English speaking customers, I don't believe there was any conscious intention to short change. But that was before UTF-8 was invented. Essentially UTF-8 is the answer, it's a protocol by which computers can communicate text to each other without any of the niggly problems with 16 or 32 bit chars, and it's also an extremely good way of passing data between components in the same program, especially when the majority of messages are in fact ascii. 16 bit wide character types are a mistake, Windows program break simply because the window setting up code requires the window class name to be string, leading to a whole rigmarole of A and W twin functions for code that isn't even doing any text processing.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-25 19:42 -0400 |
| Message-ID | <X9Vsx.169757$Xi4.111835@fx09.iad> |
| In reply to | #66353 |
On 7/25/15 4:14 PM, glen herrmannsfeldt wrote: > Richard Damon <Richard@damon-family.org> wrote: >> On 7/25/15 12:43 PM, James Kuyper wrote: > > (snip on extension for types smaller than char) >>> The extension, as I understand it, means that the result of a sizeof >>> expression is normally of type size_t, but has some kind of floating >>> point type when applied to types like tiny_t. In that case, >>> sizeof(char)/2 would be evaluated as an integer expression with a value >>> of 0, while the multiplication and both equality comparisons would be >>> evaluated in that floating point type. Therefore, the first would be >>> true, and the second would be false. > >> Not quite, the extension described having size_t being some form of >> extended type that supported some fractional values as an 'extension' to >> the standard. That doesn't work. > >> If sizeof(tiny_t) doesn't return a size_t but some other type (the idea >> here isn't a 'floating point' type, but more likely a scaled type with a >> fixed and limited fraction) it might be possible to work out rules to >> make it a conforming extension, but I am not so sure. > > Seems to me another choice is a new operator like sizeof, but different. Like I mentioned in the paragraph you snipped ;) > > This problem will become more common if systems move to a 16 bit > unicode char, but want to keep an 8 bit type. > > (snip) > > -- glen > Systems are unlikely to 'move' to 16 bit Unicode. 16 bit Unicode would be UTF-16 which has all the problems of UTF-8 (maybe some of them less often, but that just means bugs hide better), and is in general less efficient for storing data, unless you data is very strongly biased to CJK data. (You need to have more of the base plane CJK characters which use 1 UFT-16 code unit but 3 UTF-8 code units than ordinary Ascii characters (like space, and new line, or most markup code). UCS-2 is pretty much dead except in legacy systems that chose it before the Unicode Consortium realized that 16 bits wasn't going to be enough. Windows made this mistake, and first adopted USC-2 as its encoding for text, but later changed this to UTF-16, but I suspect many programs will 'mistakenly' treat the data as UCS-2 (and likely not have any problems with it, just as they wouldn't have problems treating UTF-8 as ASCII).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-30 12:16 -0700 |
| Message-ID | <kfnr3npcv7u.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66346 |
Richard Damon <Richard@Damon-Family.org> writes: > On 7/25/15 12:43 PM, James Kuyper wrote: >> On 07/25/2015 11:07 AM, Richard Damon wrote: >>> On 7/24/15 11:13 PM, Martin Shobe wrote: >>>> On 7/24/2015 7:03 PM, Richard Damon wrote: >>>>> On 7/24/15 12:49 PM, Tim Rentsch wrote: >>>>> >>>>>> That's true, but the Standard also allows extensions. If types >>>>>> narrower than CHAR_BIT bits were provided as an extension, >>>>>> doesn't it seem reasonable to also extend sizeof to give a >>>>>> non-integral value for those types (not to be confused with >>>>>> 'extended integer types', which has a specific meaning)? I don't >>>>>> see any reason why there couldn't be such an extension, provided >>>>>> of course the usual condition about strictly conforming programs >>>>>> holds. >>>>> >>>>> Extension should not change the defined behavior of things and MUST NOT >>>>> change the behavior of a strictly conforming program. >>>>> >>>>> Let us assume that we have this strange size_t that can express >>>>> fractions of at least 1/2 (0.5), and the type with that size is tiny_t >>>>> >>>>> I presume you intend that 2*sizeof(tiny_t) == sizeof(char) and that >>>>> sizeof(tiny_t) == sizeof(char)/2 >>>> >>>> I don't think sizeof(tiny_t) would equal sizeof(char)/2. The first would >>>> need to hold to make it a useful extension. >>>> >>>> [snip] >>> >>> It would be a very strange type of math where x * 2 / 2 != x (assuming >>> no overflow). >> >> The extension, as I understand it, means that the result of a sizeof >> expression is normally of type size_t, but has some kind of floating >> point type when applied to types like tiny_t. In that case, >> sizeof(char)/2 would be evaluated as an integer expression with a value >> of 0, while the multiplication and both equality comparisons would be >> evaluated in that floating point type. Therefore, the first would be >> true, and the second would be false. > > Not quite, the extension described having size_t being some form > of extended type that supported some fractional values as an > 'extension' to the standard. That doesn't work. > > If sizeof(tiny_t) doesn't return a size_t but some other type (the > idea here isn't a 'floating point' type, but more likely a scaled > type with a fixed and limited fraction) it might be possible to > work out rules to make it a conforming extension, but I am not so > sure. There likely will be some surprises. Some questions, will > void* be able to hold a tiny_t* (and round trip a value), or do we > need another extension to create an extended equivalent of void > with the extra information needed? I suppose also that converting > this extended size_t to a size_t (for example to call malloc) will > round any fractions up, I would need to think about this longer to > make sure that there aren't other situations where you really want > it to round down! One case where you would need to be very > careful is using things like memset on an array of tiny_t, > especially if we want to clear an odd number of elements, it won't > work right. [snip] I guess I should have posted an outline of some sort to explain some of the details. Let me do that here. Pointers all have bit-level addressibility. No extension is needed to do this, it's just part of the representation that falls under an implementation's purview anyway. The types size_t and ptrdiff_t have a few extra bits to be able to represent fractional values. All fractional values are tecnically trap representations. Fractional values add and subtract appropriately, multiply appropriately, divide appropriately for denominators that would produce a multiple of the smallest positive fractional value, and a bit to remember their "fractionalness". No extension is needed for any of these choices, they all fall under the implementation's purview for representation and for undefined behavior, which happens if a fractional size_t or ptrdiff_t is ever loaded. In necessary size_t and ptrdiff_t are respectively uintmax_t and intmax_t so that any operations take place in types that can handle fractionalness appropriately. (There are other ways of doing that, this way is just the easiest to explain.) The operations for sizeof, taking address, and pointer arithmetic (which subsumes indexing), are extended to produce the "special" values when working with any undersized types. So for example, taking CHAR_BIT == 16 and an __octet type that is 8 bits, sizeof (char) is 1, whereas sizeof (__octet[2]) is 1 but with the fraction bit turned on so when divided by 2 it yields the fraction 1/2. All library functions like memcpy() and malloc() deal with non-char-aligned pointers and fractional sizes as you would expect, given that the information is there in the pointers and in the sizes. Does this all make sense? Is there anything else that needs explaining?
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-30 22:04 +0100 |
| Message-ID | <mpe3er$1es$1@dont-email.me> |
| In reply to | #66576 |
On 30/07/2015 20:16, Tim Rentsch wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> >> If sizeof(tiny_t) doesn't return a size_t but some other type (the >> idea here isn't a 'floating point' type, but more likely a scaled >> type with a fixed and limited fraction) it might be possible to >> work out rules to make it a conforming extension, but I am not so >> sure. There likely will be some surprises. Some questions, will >> void* be able to hold a tiny_t* (and round trip a value), or do we >> need another extension to create an extended equivalent of void >> with the extra information needed? I suppose also that converting >> this extended size_t to a size_t (for example to call malloc) will >> round any fractions up, I would need to think about this longer to >> make sure that there aren't other situations where you really want >> it to round down! One case where you would need to be very >> careful is using things like memset on an array of tiny_t, >> especially if we want to clear an odd number of elements, it won't >> work right. [snip] > > I guess I should have posted an outline of some sort to explain > some of the details. Let me do that here. > > Pointers all have bit-level [addressability]. No extension is > needed to do this, it's just part of the representation that > falls under an implementation's purview anyway. No, you can't just brush these details under the carpet, or make it someone else's problem. On the vast majority of computer systems, pointers have 8-bit addressability at best. > The types size_t and ptrdiff_t have a few extra bits to be able > to represent fractional values. All fractional values are > tecnically trap representations. Fractional values add and > subtract appropriately, multiply appropriately, divide > appropriately for denominators that would produce a multiple of > the smallest positive fractional value, and a bit to remember > their "fractionalness". No extension is needed for any of these > choices, they all fall under the implementation's purview for > representation and for undefined behavior, which happens if a > fractional size_t or ptrdiff_t is ever loaded. In necessary > size_t and ptrdiff_t are respectively uintmax_t and intmax_t > so that any operations take place in types that can handle > fractionalness appropriately. (There are other ways of doing > that, this way is just the easiest to explain.) .... > Does this all make sense? Is there anything else that needs > explaining? On 64-bit systems, they will have the spare capacity to store the extra range needed by size_t and for pointers; 32-bit systems won't. But on both there will be extra overheads to deal with those pesky extra bits which will have to be encoded in some unusual way even if the space is there for them. (I think that sub-char types are special enough that they can treated apart. So sizeof(), size_t, char*, void*, ptrdiff etc work as normal and at full efficiency. For sub-char types, there can be a special set of types and operators, such as bitsizeof(), bitsize_t, T* (where T is sub-char), and so on. Void* is a little tricky because you don't want that doubling in size (as will happen on some systems), just to accommodate some 4-bit char type or whatever. So I would use bitvoid* (not necessarily with that name...).) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-02 06:10 -0700 |
| Message-ID | <kfntwshalas.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66584 |
Bartc <bc@freeuk.com> writes: > On 30/07/2015 20:16, Tim Rentsch wrote: >> Richard Damon <Richard@Damon-Family.org> writes: > >>> >>> If sizeof(tiny_t) doesn't return a size_t but some other type (the >>> idea here isn't a 'floating point' type, but more likely a scaled >>> type with a fixed and limited fraction) it might be possible to >>> work out rules to make it a conforming extension, but I am not so >>> sure. There likely will be some surprises. Some questions, will >>> void* be able to hold a tiny_t* (and round trip a value), or do we >>> need another extension to create an extended equivalent of void >>> with the extra information needed? I suppose also that converting >>> this extended size_t to a size_t (for example to call malloc) will >>> round any fractions up, I would need to think about this longer to >>> make sure that there aren't other situations where you really want >>> it to round down! One case where you would need to be very >>> careful is using things like memset on an array of tiny_t, >>> especially if we want to clear an odd number of elements, it won't >>> work right. [snip] >> >> I guess I should have posted an outline of some sort to explain >> some of the details. Let me do that here. >> >> Pointers all have bit-level [addressability]. No extension is >> needed to do this, it's just part of the representation that >> falls under an implementation's purview anyway. > > No, you can't just brush these details under the carpet, or > make it someone else's problem. > > On the vast majority of computer systems, pointers have 8-bit > addressability at best. I think you have misunderstood what the discussion is about. Such considerations are not relevant to the point I am making.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-25 19:10 -0700 |
| Message-ID | <31ba259f-4dbd-42aa-83a5-507883a9bf3c@googlegroups.com> |
| In reply to | #66334 |
On Saturday, July 25, 2015 at 8:07:55 AM UTC-7, Richard Damon wrote:
> On 7/24/15 11:13 PM, Martin Shobe wrote:
> > On 7/24/2015 7:03 PM, Richard Damon wrote:
> >> On 7/24/15 12:49 PM, Tim Rentsch wrote:
> >>
> >>> That's true, but the Standard also allows extensions. If types
> >>> narrower than CHAR_BIT bits were provided as an extension,
> >>> doesn't it seem reasonable to also extend sizeof to give a
> >>> non-integral value for those types (not to be confused with
> >>> 'extended integer types', which has a specific meaning)? I don't
> >>> see any reason why there couldn't be such an extension, provided
> >>> of course the usual condition about strictly conforming programs
> >>> holds.
> >>>
> >>
> >> Extension should not change the defined behavior of things and MUST NOT
> >> change the behavior of a strictly conforming program.
> >>
> >> Let us assume that we have this strange size_t that can express
> >> fractions of at least 1/2 (0.5), and the type with that size is tiny_t
> >>
> >> I presume you intend that 2*sizeof(tiny_t) == sizeof(char) and that
> >> sizeof(tiny_t) == sizeof(char)/2
> >
> > I don't think sizeof(tiny_t) would equal sizeof(char)/2. The first would
> > need to hold to make it a useful extension.
> >
> > [snip]
> >
> > Martin Shobe
> >
>
> It would be a very strange type of math where x * 2 / 2 != x (assuming
> no overflow).
I can see an arithmetic where the result of a / b is, rather than a
single value, the pair of values now written a/b and a%b. This is what
the computer actually did (and a decent optimizer knows it). Then the
true equation is something like
quotient (x*2/2) == x.
I seriously doubt that anyone really wants to go this way - but it is
feasible and closer to reality than the preferred notation.
PS Multiplication would demand, for full consistency, to be written
a * b + c
but I suppose we could say that if there is no c term c is zero.
now wr
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-25 22:16 -0400 |
| Message-ID | <0qXsx.191356$kh3.148377@fx08.iad> |
| In reply to | #66384 |
On 7/25/15 10:10 PM, David Kleinecke wrote: > > I can see an arithmetic where the result of a / b is, rather than a > single value, the pair of values now written a/b and a%b. This is what > the computer actually did (and a decent optimizer knows it). Then the > true equation is something like > quotient (x*2/2) == x. > > I seriously doubt that anyone really wants to go this way - but it is > feasible and closer to reality than the preferred notation. > > PS Multiplication would demand, for full consistency, to be written > a * b + c > but I suppose we could say that if there is no c term c is zero. > now wr > But the C Standard has LONG defined how integer division works, and to change this would be a MAJOR breaking change, 1 / 2 will always be 0 and thus 1 / 2 * 2 will also always be 0.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-07-25 19:46 -0700 |
| Message-ID | <37f26c97-8ecc-4469-bf55-990070bc2c31@googlegroups.com> |
| In reply to | #66385 |
On Saturday, July 25, 2015 at 7:16:41 PM UTC-7, Richard Damon wrote: > On 7/25/15 10:10 PM, David Kleinecke wrote: > > > > I can see an arithmetic where the result of a / b is, rather than a > > single value, the pair of values now written a/b and a%b. This is what > > the computer actually did (and a decent optimizer knows it). Then the > > true equation is something like > > quotient (x*2/2) == x. > > > > I seriously doubt that anyone really wants to go this way - but it is > > feasible and closer to reality than the preferred notation. > > > > PS Multiplication would demand, for full consistency, to be written > > a * b + c > > but I suppose we could say that if there is no c term c is zero. > > now wr > > > > But the C Standard has LONG defined how integer division works, and to > change this would be a MAJOR breaking change, 1 / 2 will always be 0 and > thus 1 / 2 * 2 will also always be 0. Ah but you didn't say you were talking C standard. You said "arithmetic" and that throws you into general mathematics. I pointed out that this possibility was not something I expected anyone to advocate for.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-30 11:52 -0700 |
| Message-ID | <kfnvbd1cwbk.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66322 |
Richard Damon <Richard@Damon-Family.org> writes: > On 7/24/15 12:49 PM, Tim Rentsch wrote: > >> That's true, but the Standard also allows extensions. If types >> narrower than CHAR_BIT bits were provided as an extension, >> doesn't it seem reasonable to also extend sizeof to give a >> non-integral value for those types (not to be confused with >> 'extended integer types', which has a specific meaning)? I don't >> see any reason why there couldn't be such an extension, provided >> of course the usual condition about strictly conforming programs >> holds. > > Extension should not change the defined behavior of things and > MUST NOT change the behavior of a strictly conforming program. The presence of undersized types is limited (eg, by needing an include line like #include <Xstdint.h>) to programs that are not strictly conforming. So it is guaranteed that the extension will not change the behavior of any strictly conforming program. As for extensions not changing the defined behavior of things, I believe the Standard does not require that. But in any case the extension does not change any behavior for things that were there without the extension. The behaviors of sizeof, &, and pointer arithmetic are all exactly the same as they would be when applied to non-extension types. > Let us assume that we have this strange size_t that can express > fractions of at least 1/2 (0.5), and the type with that size is > tiny_t > > I presume you intend that 2*sizeof(tiny_t) == sizeof(char) Yes, that is easy to do. > and that sizeof(tiny_t) == sizeof(char)/2 That isn't necessary. This case is similar to comparing a floating point expression and an integer expression, for example, 0.5 == 1/2. We aren't surprised when that comparison yields 0. > This violates the above rule as a strictly conforming program can > do assert(sizeof(char)/2 * 2 == 0) and not have the assert fire, > but it will in your case. (sizeof(char) MUST be 1, as an integral > type, 1/2 MUST be 0, and 0*2 MUST be 0) As I have just explained the comparison will yield consistent results, and any comparison involving any undersized types will necessarily involve non-strictly conforming programs.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-07-31 08:51 +0000 |
| Message-ID | <55bb368e.704218@news.xs4all.nl> |
| In reply to | #66574 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > Richard Damon <Richard@Damon-Family.org> writes: > > > Extension should not change the defined behavior of things and > > MUST NOT change the behavior of a strictly conforming program. > > The presence of undersized types is limited (eg, by needing an > include line like #include <Xstdint.h>) to programs that are > not strictly conforming. So it is guaranteed that the extension > will not change the behavior of any strictly conforming program. Oh, well, in that case... In a non-conforming program, you're welcome to use Pascal variant records, ZMachine Objects, matchboxes with pieces of paper in them, and yes, also undersized integers. But you're outside what can be reasonably argued about with reference to the C Standard, then. Richard
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web