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: Compiling and linking code from different places in the file system Date: Fri, 09 Mar 2018 12:27:40 -0800 Organization: None to speak of Lines: 80 Message-ID: References: <6oSnC.178019$eQ7.108635@fx46.am4> <87o9k055d2.fsf@bsb.me.uk> <13a67039-e46b-4337-a1a3-058210e55b6e@googlegroups.com> <2c91fbad-d3aa-40b7-88a7-124845c1201f@googlegroups.com> <748d0aaa-e82a-4437-b6bd-f70e69c82904@googlegroups.com> <601fd63c-4613-4892-9dd6-8fe8cc61c043@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="bb2cdd46fc14bf16d0e6a78dcd8fc907"; logging-data="15034"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Xcgn1Sb/YZ2ASTEckQTxQ" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:vJqIfRo6r2ymwaT5fZzSxXKJ/5s= sha1:P5TQYv+LyZJky0IsEu94fLkKEQs= Xref: csiph.com comp.lang.c:127593 supercat@casperkitty.com writes: > On Friday, March 9, 2018 at 2:59:27 AM UTC-6, David Brown wrote: >> On 08/03/18 22:36, supercat@casperkitty.com wrote: >> > I will acknowledge that it has become fashionable for implementations >> > where a 32-bit long would have been practical, to define long to be a >> > different size. >> >> You are joking, right? 64-bit "long" is 30 years old at least. And >> that is not including specialist systems like Crays, which have had >> 64-bit long since their first C compiler (and, I believe, 64-bit char, >> short and int). > > What common microprocessor implementation dating back to 1988 was using > a 64-bit "long"? He didn't mention "common microprocessor implementations". Stop moving the goalposts. I'm not sure what non-Cray implementations would have had 64-bit long in 1988, but I can easily believe that there were some. In any case, I don't see the point of assuming there weren't. (K&R1 mentions the Honeywell 6000, which had 36-bit long.) > I'll grant that until the Standard was changed to allow > a compiler to treat "long long int" as a different type from "long int" [if > I recall, C89 specified that repeated modifiers be ignored, and also > specified that printf must ignore repeated formatting flags] it's possible > that some compiler vendors may not have felt there was any other way to > handle 64-bit values. You recall incorrectly. The wording of C90 6.5.2 is perhaps ambiguous, but my interpretation (and that of most or all compilers I know about) is that "long" cannot be repeated in a list of type specifiers. Constraints Each list of type specifiers shall be one of the following sets (delimited by commas, when there is more than one set on a line); the type specifiers may occur in any order. possibly intermixed with the other declaration specifiers. - void - char [...] - long, signed long, long int, or signed long int [...] "long long x;" would be a constraint violation for exactly the same reason that "int int y;" would be. (Some C90 compilers might support "long long" as an extension, a conforming one as long as a diagnostic is issued.) (Modern C compilers operating in C90 mode use a different diagnostic, saying that C90 doesn't support "long long".) > On the other hand, it was useful having a printf > formatting flag that would be usable to output 32 bit values on systems > where "int" was either 16 or 32 bits. printf formatting flags correspond to types, not to sizes. It has always been that way. If you want to print a 32-bit value, you need to use a flag that corresponds to the *type* of the value you're printing. There is no printf format for "32-bit integer". There are distinct formats for int and long, even if they both have the same representation, and using "%d" for a long value or "%ld" for an int value has undefined behavior (though it's likely to "work" if int and long have the same representation). I think we all agree that using "%ld" with a cast is a bit ugly, so you can stop repeating that point. [...] > The handling of printf arguments is ugly. Life is hard. [...] -- 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"