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: Thu, 08 Mar 2018 10:28:39 -0800 Organization: None to speak of Lines: 137 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="d5db3c990c5a8317a11173691196aced"; logging-data="14043"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/aHM8LLASghMYhdrk7Fbsq" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:NZZi0n7AWo6C//Mp/DR4Xk8jG7w= sha1:LzZRUI3bP2Md69SYwY6oPpzxJSs= Xref: csiph.com comp.lang.c:127491 supercat@casperkitty.com writes: > On Wednesday, March 7, 2018 at 9:18:49 PM UTC-6, Keith Thompson wrote: >> supercat@casperkitty.com writes: >> > On Wednesday, March 7, 2018 at 2:01:32 PM UTC-6, Keith Thompson wrote: >> [...] >> >> 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). >> > >> > Some embedded platforms have a limited range of compilers available. If >> > one needs to update the code for a piece of existing hardware which uses >> > an obscure platform, it may not be possible to use a C99 compiler. >> >> It wasn't clear that you were talking about workaround for ancient >> compilers. See, for example, . > > Even in the days before C99, it was possible to write code for bit- > crunching purposes like data compression, encryption, etc. which would > be portable to most microcomputer C implementations with one configuration > change. A model where "int" may be 16 or 32 bits but "long" is 32 bits > will make it possible to use concise and legible printf format strings to > output different sized types: > > "%d" etc. will represent anything which is not bigger than "int". > "%ld" etc. will represent 32-bit integers. > "%lld" etc. will represent 64-bit integers. > > Which of the following would you consider more legible: > > uint32_t x,y; uint16_t small; uint64_t big > printf("x=%ld y=%ld small=%d big=%lld", x, y, small, big); > or > printf("x=%" PRId32 " y=%" PRId32 " small=%" PRId16 " big=%" PRId64, > x, y, small, big); > > The former will work on platforms where int is 16 or 32 bits and long is > 32 bits. The latter would also work on platforms where long is 64 bits, > but I would regard it as less legible than the first. > > I'm well aware that in the LP64 type system the first way of writing the > code would need to be adjusted to: > > printf("x=%d y=%d small=%d big=%lld", x, y, small, big); > > but that would make the code unusable on low-cost micros with 16-bit "int". Are you seriously advocating writing code that assumes long is exactly 32 bits? Will you at least acknowledge that such code would break on many modern systems? How is the readability of code that doesn't work relevant? I'm just about to give up trying to understand whatever point you're trying to make. >> > [...] but I'm curious what >> > justification there is for code that would require "long" to be 64 bits. >> >> You were talking about code that assumes long is 32 bits; such code >> would break on many of the systems I use. I prefer to assume that long >> is at least 32 bits, since that's what the language guarantees. > > There are three ways a program can use printf [and sprintf, etc.] > > 1. Use the clunky macros defined in C99. That works, but I don't think > those macros are very legible. Do you? I rarely use them myself. > 2. Use it in a way that assumes "%d" is appropriate for 32-bit types. > Low-cost microcontrollers could not efficiently support code written > in this way. I don't do that, because it doesn't work. Why mention it? > 3. Use it in a way that assumes that "%ld" is appropriate for outputting > 32-bit types. Implementations targeting 64-bit systems could have > efficiently supported code written this way, though I am well aware > that for some reason many have opted not to. I don't do that, because it doesn't work. Why mention it? > 4. Cast 32-bit arguments to "long" and then use "%ld". That would work, > and is a bit less ugly than the PRI* macros, but it's hardly elegant. I sometimes use "%jd" with a cast to intmax_t, or "%ju" with a cast to uintmax_t, if I'm not sure which predefined type the argument has (though I use "%zu" for size_t). "%ld" can fail if the argument is wider than long. In the unlikely case that I have to worry about pre-C99 implementations, I'll use "%ld with a cast to long. I agree that it's hardly elegant, but it works. >> >> 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. >> > >> > Not every build system uses Unix. >> >> How does the phrase "configuration script" imply Unix? > > In what other context would someone who supplies code with a configuration > script expect that script to be useful to anyone who is not familiar with > the particular build system for which it is designed. I don't do much work on non-Unix systems, but I presume the people who do have come up with ways to do what Unix configuration scripts do. >> > A configuration script will only be usable on build systems that support the >> > tools it's designed to work with. A text file that says to invoke the >> > compiler in a way that pre-defines either BIG_ENDIAN or LITTLE_ENDIAN will >> > work on any compiler that allows macros to be pre-defined at the time of >> > invocation. >> >> Sure, that would work too. (You can think of that text file as a >> trivial configuration script if you like.) Making sure that it's >> defined correctly is left as an exercise. > > The human-readable text file would be portable to any compiler that has the > proper options, when used by anyone who can understand whatever human > language the text file is written in. Wait, you're talking about a file written in English (or some human language)? How does the information get from that file to the compiler? Are you talking about something like: If the system is big-endian, compile with "cc -DBIG_ENDIAN". If the system is little-endian, compile with "cc -DLITTLE_ENDIAN". and requiring the use to follow the instructions? If so, that's a *huge* step backwards. We have these things called "computers" that are really useful for automating things. -- 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"