Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C needs to evolve Date: Sun, 03 Dec 2017 23:02:22 -0800 Organization: None to speak of Lines: 42 Message-ID: References: <4d2a3d73-c48a-46e4-96ae-034dc6ae7ea1@googlegroups.com> <9be489e6-8c1e-4d5a-83f8-35960e6b28e3@googlegroups.com> <37613bba-407c-431b-bdd7-d1832da0dd28@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="29610526d8bebf943bd72be7aa353e32"; logging-data="12847"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/iwgwWirLVnMyhVr7n8tdG" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:IEBo323zq0yI9Tm4kSZqz3KQ7Sk= sha1:eaP5P5cw3J+EpVCYQcvCinaNBMk= Xref: csiph.com comp.lang.c:123792 Felipe Ferreira writes: > On Sunday, December 3, 2017 at 1:42:15 AM UTC-3, Keith Thompson wrote: >> You snipped the part where I asked for specific examples of standard >> library functions where types defined in would work better >> than the types currently used. Do you have such examples? > > Like I said, it's about conformance. That's the whole advantage. The > string library would benefit from that. If you are working with > networking, you might be working with different architectures and > knowing that that a int8_t/int16_t/int32_t in one is equal to a > int8_t/int16_t/int32_t in the other will save a lot of pain knowing > that the the functions that you used were specific for > int8_t/int16_t/int32_t and will behave the same in both different > architectures. You will know that certain data structure will have the > same size, making sure that sending one through network and > mem-copying on the other end will work. How is it about conformance? In a conforming implementation, strlen() return a result of type size_t, which is the type used to represent sizes. It might be 16, 32, or 64 bits, or even some other size -- and it's easy enough to find out which. Exactly what change are you suggesting? Data structures are generally *not* binary-compatible across architectures. That's not just because of size, you also have to consider alignment and endianness. > On Saturday, December 2, 2017 at 11:56:21 PM UTC-3, Richard Damon wrote: [...] >> int16_t and int32_t might not exist, so really can't be used. > > True, but that would be a case of non conformance. Not at all. The intN_t types are optional (N1570 7.20.1.1p3). [...]. -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"