Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Something C might need Date: Sat, 23 Sep 2017 17:49:51 -0700 Organization: None to speak of Lines: 42 Message-ID: References: <1cc86992-d71e-42b9-818f-f883b78e79ce@googlegroups.com> <7ac3b44a-b838-4462-88c8-adcd77d61ce1@googlegroups.com> <0a5d39ba-fc96-4fea-922d-bcb4b0db0c32@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="f340375e532714dc24c747dfdddc9b11"; logging-data="1643"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/OTtbqfpXFGUoA5R43QQt4" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:IexlX331Tm2SGmQTxxcwfjEvuTs= sha1:qGvI3W+2DOnl7pDAq/4vsxMuvYc= Xref: csiph.com comp.lang.c:120214 supercat@casperkitty.com writes: > On Saturday, September 23, 2017 at 5:29:40 AM UTC-5, Bart wrote: >> In that case it's easy: >> >> char 8 bits >> short 16 >> int 32 >> long 64 >> long long 128 (Optional) > > How about allowing the sizes to be configured via compiler options or > directives that precede the first usage of the types in question? How about having a distinct copy of the entire standard library (which is largely defined in terms of the existing predefined types) for each supported combination of user-defined sizes? On my system, I can compile a program with default options (x86_64), with "-m32" (x86), and with "-mx32". Each generates an executable that links to a lib.so file (which provides the standard library implementation) in a different directory. That's not a real problem. Each option essentially specifies a distinct target environment, and each environment needs its own library implementation. But letting the user specify the characteristics of the environment would cause the problem space to blow up. Infinite flexibility has a cost. It wouldn't be terribly difficult to do as you suggest. I suspect it hasn't been done because it truly wouldn't be very useful. We already have integer types of all useful sizes. Arbitrarily mapping them to C's predefined types names doesn't buy us much. (Yes, I know about the issues with arithmetic on types narrower than int.) [...] -- 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"