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: Wed, 07 Mar 2018 12:01:22 -0800 Organization: None to speak of Lines: 106 Message-ID: References: <6oSnC.178019$eQ7.108635@fx46.am4> <87o9k055d2.fsf@bsb.me.uk> <13a67039-e46b-4337-a1a3-058210e55b6e@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="1b894f1eb6e5831da76153652d9177c0"; logging-data="6815"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+fDu4oQg061eowinpaws0u" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:/LFADH14RneAaZSWkkZCsi1W2NE= sha1:leLIZXJn6z8o9+o+dqcFw3WhkTE= Xref: csiph.com comp.lang.c:127449 supercat@casperkitty.com writes: > On Wednesday, March 7, 2018 at 12:11:15 PM UTC-6, Keith Thompson wrote: >> supercat@casperkitty.com writes: >> [...] >> > If instead a program can be designed so that it will work with any common >> > microprocessor platform where char, short, and long are 8, 16, and 32 bits, >> > respectively, are consistently big-endian or little-endian, and allow such >> > representation to be accessed using lvalues of any integer type which are >> > visibly derived in the context where they are used, and if such code >> > requires that either BIG_ENDIAN or LITTLE_ENDIAN be pre-declared, then >> > the code could be expected to be usable on any development system meeting >> > those requirements without having to be tested on every single one of them. >> >> Consider. Writing. Shorter. Sentences. >> >> Any program that assumes 32-bit long will fail on many of the systems I >> use, where long is 64 bits. How about writing code that doesn't assume >> how wide long is? > > A lot of code was written before C99 added int32_t and uint32_t as > standards. The closest things to standard 32-bit type were "long" and > "unsigned long", and an assumption that "long" would be 32 bits was > about as portable as an assumption that "char" would be eight. A > machine with 36-bit words wouldn't have a 32-bit long, but it wouldn't > have an 8-bit "char" either. Yes, but int32_t and uint32_t do exist now. Are you looking for new and improved ways to update the C90 standard? They did that, and it's called C99 (and C11). Type long is very commonly 64 bits these days. If you want to write code that assumes it's 32, you can always write: #if LONG_MAX != 0x7fffffff #error "long is not 32 bits" #fi Or, you can use int32_t and uint32_t. > Further, a program could provide users of platforms where e.g. "int" is > 32 bits but "long" is bigger with instructions for how to deal with that, > e.g. by starting with > > #ifndef I32_TYPE > #define I32_TYPE long > #endif > #ifndef U32_TYPE > #define U32_TYPE unsigned long > #endif > > and instructing users of such platforms to predefine "I32_TYPE" as a macro > which describes a signed 32-bit type, and U32_TYPE as a macro which describes > an unsigned 32-bit type. Users of more common implementations wouldn't have > to worry about defining such macros. Are you trying to reinvent int32_t and uint32_t? Why?? >> No conforming implementation can predefine BIG_ENDIAN or LITTLE_ENDIAN. > > Most quality implementations can easily be configured for a non-conforming > mode in which such symbols are defined, using a command-line option like > "-dBIG_ENDIAN". Alternatively, code could be shipped with an essentially- > empty "opts.h" file which is the first thing included by each other file, > and which could be edited if necessary to pre-define any macros needed > elsewhere. My point is simply that if such macros are to be added in a future standard, either they'll have to be in the implementation-reserved namespace (_BIG_ENDIAN, _LITTLE_ENDIAN), or they'll have to be in a new standard header, or they'll risk breaking existing code. The latter isn't necessarily a show-stopper. C99 broke C90 code that included and defined LLONG_MAX, and I don't think that was a problem. >> And most code doesn't need to care about endianness. I wouldn't mind >> having a way to determine the current system's endianness, (maybe >> something in ), but it's not a huge deal. > > It can be important for code that handles things like encryption, big-number > math, CRC calculations, etc. Not the most common usages, but not ones that > should be totally ignored either. Is the lack of predefined BIG_ENDIAN and LITTLE_ENDIAN macros (however they're spelled) a real problem for people writing such code? It's not hard to incorporate that into a configuration script. > On the other hand, before anything like that could be added to limits.h in > any standard way, there would first have to be agreement that there are > four common ways of associated the bits of a "uint32_t" with the bits of > the underlying bytes, and that the other (32!-4) mappings are sufficiently > unusual as to justify lumping them into an "other" category. Four common ways? I'd say two (big-endian and little-endian) should be sufficient. Are there middle-endian platforms other than the PDP-11? Are there likely to be conforming C202Y implementations for such platforms? I have no particular objection to adding something to, say, that would let an implementation specify whether it's big-endian, little-endian, or something else, though I'm skeptical that it's worthwhile. -- 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"