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 18:03:15 -0700 Organization: None to speak of Lines: 100 Message-ID: References: <1cc86992-d71e-42b9-818f-f883b78e79ce@googlegroups.com> <7ac3b44a-b838-4462-88c8-adcd77d61ce1@googlegroups.com> <87wp4p4sej.fsf@bsb.me.uk> <87o9q14343.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="f340375e532714dc24c747dfdddc9b11"; logging-data="9966"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1993rD69kjpqYYqKBndcwHK" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:du8Ec0Aau+MOIhoh5Te0X3crR1U= sha1:Zeuqgo5Hx6fVFsPHVxKcmuJXaMs= Xref: csiph.com comp.lang.c:120215 David Kleinecke writes: > On Saturday, September 23, 2017 at 12:38:44 PM UTC-7, Ben Bacarisse wrote: >> David Kleinecke writes: >> >> > On Saturday, September 23, 2017 at 3:32:27 AM UTC-7, Ben Bacarisse wrote: >> >> David Kleinecke writes: >> >> >> >> > On Friday, September 22, 2017 at 6:20:35 PM UTC-7, Keith Thompson wrote: >> >> >> David Kleinecke writes: >> >> >> [...] >> >> >> > Assuming the hardware arithmetic is 64-bit then I think it >> >> >> > would be best to have "short" be 32-bit, char 8-bit and >> >> >> > 16-bit "long char". "Wide char" would be more standard but >> >> >> > why introduce a new keyword. "Short short" for 16-bit would >> >> >> > be in the spirit of "long long" (which I assume no longer >> >> >> > would exist). >> >> >> >> >> >> How much existing code do you want to break? >> >> > >> >> > Ah ha - a major difference in viewpoint. >> >> > >> >> > I wasn't addressing existing code at all. I have no >> >> > desire to even bend any of it. If "long long" no longer exists, all code that depends on it would break. Is that not obvious? >> >> You appeared to suggest the removal of two of standard C integer >> >> types (long long int and, presumably, long long unsigned). >> > >> > I work from C89 so "long long" isn't part of what I talked >> > about But you're talking about some future language, or future *something*. Are you proposing a new language based on C89? >> You talked about it. I no longer think I know what you said about it, >> but you definitely talked about it. The words you used seemed to >> suggest that it would not longer exist. >> >> > but it is obvious what it means - a value twice as >> > long as a long. >> >> How could that be obvious? It's not what C means by long long, and you >> seemed to suggest that long long would no longer exist according to some >> plan of yours. That would leave only two obvious possibilities: (a) >> that long long would not longer exist; or (b) that long long would >> remain what it always was which is /not/ twice as long as long. > > I'm not trying to lay down any laws. All I insist on as > a desideratum is that "int" mean whatever the arithmetic > execution register's(s'?) length is. The other possible > variable sizes are (aside from "char") specified as > "short", "long", "short short" etc. - "long" meaning > "twice" and "short" meaning "half". You can insist on anything you like. It matters only if you define your own non-C language, which you'd then be free to discuss elsewhere. If you're talking about C, the answer is going to be "no". In C, "long" does not mean twice, and "short" does not mean half, and they never have. (The PDP-11 had 16-bit short, 16-bit int, and eventually 32-bit long.) > Note that all the various "short"s are effectively storage > only concepts just like "char". I think the standards allow > this. That depends on what you mean by "storage only concepts". In actual C, short and int are both integer types. Values of type short are promoted to a wider type before any arithmetic operations are applied to them, but conversions can be applied directly to values of narrow types. > How "long"s work would be implementation-defined. I > think the usual assumption is that a "long" looks, under the > hood, like a two-member struct - both members "int". A > "long long" would, I think, be like a four member struct of > "int" or a two member struct of "long". That bears no apparent resemblance to the way C's long and long long types work. What language are you talking about? > I am assuming that the memory fetch size is the same as the > arithmetic register. It could be smaller but if it were > larger I don;t understand where the excess bytes go. There's no requirement in C for int to be the size of a register. It is intended to have "the natural size suggested by the architecture of the execution environment", but that's vague enough that different implementations for the same CPU can have different sizes for int (though it's commonly constrained by an ABI). I'm typing this message on a system with 64-bit registers and 32-bit ints. -- 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"