Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #127501
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Compiling and linking code from different places in the file system |
| Date | 2018-03-08 22:17 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <p7s98t$hs4$1@dont-email.me> (permalink) |
| References | (8 earlier) <afce8849-eec5-4828-b141-3df0a9f7bb3b@googlegroups.com> <lny3j3eoxy.fsf@kst-u.example.com> <13a67039-e46b-4337-a1a3-058210e55b6e@googlegroups.com> <p7qvnq$n21$1@dont-email.me> <f9079c41-514f-4309-b5cd-6ed16b8111f9@googlegroups.com> |
On 08/03/18 19:28, supercat@casperkitty.com wrote: > On Thursday, March 8, 2018 at 3:28:38 AM UTC-6, David Brown wrote: >> It is decades since 64-bit computing has been mainstream - MIPS, Alpha, >> SPARC, PPC have all had it for about 25 years or so. And "long" has >> invariably been 64-bit on these systems. Note that these all pre-date >> C99, and pre-date "long long" - a 64-bit processor would be pretty >> useless without a 64-bit type. >> >> It is /only/ x86-64 Windows that has a 64-bit processor and 32-bit "long". > > The vast majority of microcontrollers used in embedded systems use a > 32-bit "long", and a substantial fraction use 16-bit "int". Yes. > Is there any > reason why a 64-bit processor system should not be able to use code written > for a smaller micro? No, not if the C code has been written in a portable manner. Assuming that long is 32-bit is not portable and could easily result in the code failing to work on 64-bit systems. Let's put it a different way - is there any reason why you would deliberately choose to write the code in a way that relies on unwarranted assumptions that will fail on different targets, when it gives no advantages to the code you are writing? I've nothing against writing non-portable code if there is a reason for it, but you have given no valid reason. > >> "long" is almost invariably 32-bit on 8-bit, 16-bit and 32-bit >> processors. And these are the processor sizes that dominated until >> recently. Also, "long" is always /at least/ 32-bit. So certainly >> "long" has always been a popular choice for a typedef for a 32-bit type. >> >> But an /assumption/ that "long" is always 32-bit has never been a good >> idea, and has not been justifiable for many years. Even when using >> tools that did not support C99, it was common to have a <stdint.h> or >> compiler-specific header with known sizes. And when those were not >> available, it was common to use application-specific fixed-size >> typedefs. If you get a library, RTOS, or other block of code that is >> designed to be somewhat portable but supports C90, and it needs a >> specific 32-bit type (or other specific sizes), you will usually find >> that it has typedefs for these types - either automatically defined >> based on <limits.h>, or with detection for a number of compilers, or as >> a user-modified configuration header. > > No platform should have any particular difficulty supporting code that > calls printf-style functions with "%d" for 8-bit and 16-bit types, "%ld" > for 32-bit types, and "%lld" for 64-bit types. While the Standard > provides macros like PRId32, code using them is often significantly less > legible than code written using the above strings. > > The most readable way of outputting a value of a type uint32_t would probably > be to use "%lu" and then coerce or convert the value to an unsigned long, > but that seems unnecessarily clunky. Further, accidental failure to convert > or coerce the value would yield code that would work on platforms where > "long" is 32 bits, and would often work on many platforms where it is 64 > bits, but which would not be reliable on all 64-bit platforms. Not a good > combination. printf-style formatting /is/ clunky - especially for dealing with the fixed size types. I don't know of a good way to make it clear and portable. You either need these ugly macros, or casts (or some other type of conversion), or non-portable code. Or you wrap things in macros, static inline functions, etc., or use format strings that are picked depending on the details of the types underlying the uint32_t, etc. > >>> 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. >> >> That is fine - /if/ it is clear in the documentation for the code. But >> it is far better (and very simple) to have compile-time checks that the >> settings for these types are correct. > > Such compile-time checks could be included as well. The point is that if > the code is being run on a platform that defines things in suitable fashion > there should be no need for the compiler operator to take any manual action > to configure the types. > Okay... So you either include <stdint.h>, or you define the types yourself using <limits.h> and some conditional compilation. Either way, you end up with types like int32_t that are actually guaranteed to be 32-bit, rather than using "long" and crossing your fingers. >>>> 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. >> >> As Keith said, no conforming implementation can predefine these symbols. >> They are not reserved names, and user code could use them. Predefined >> symbols such as __BIG_ENDIAN__ or _LITTLE_ENDIAN would be fine, and just >> as useful. Why are you arguing against such an obvious point? > > If the code were to check whether __BIG_ENDIAN is defined, and then the > Standard were to specify that little-endian implementations should define > __BIG_ENDIAN with a value of 0, such code would need to be modified to > make it usable with compilers implementing the new standard. The name is > used without underscores because its meaning and purpose are defined by > user code rather than the Standard or implementation. No one is objecting to the idea of having something like __BIG_ENDIAN specified by the standards as a required feature of C20 (or whatever) compilers, or having it in a new standard header file. But it can't be called BIG_ENDIAN. > >> Most compilers - at least those which support more than one target - >> have something like that already. > > Some might, but they might not define such things consistently. If one > vendor might decides that a little-endian compilers should behave as though > code started with > > #define __LITTLE_ENDIAN > #undef __BIG_ENDIAN > > while another vendor might decide that the definitions should be equivalent to > > #define __LITTLE_ENDIAN 1 > #define __BIG_ENDIAN 0 > > and another might decide the proper labeling is > > #undef __LITTLE_ENDIAN // Code should use value of __BIG_ENDIAN > #define __BIG_ENDIAN 0 > > How should a programmer be expected to write code that could work with any > plausible means via which an implementation might define such symbols, > if the programmer doesn't know in advance which implementation will be used? It is generally done with a bit of pre-processor conditional compilation to check the symbols used by a range of common compilers - with some way for the code user to override things in the case of a particularly unusual compiler. Again, no one would mind the standards giving a common way to do this. It is, as has been said, not a big deal - if it /were/ a big deal, then it would have been included already. You are not the first person to think of it in the history of C standards. (C++ is getting it in C++20, if you are interested.) > >>>> 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 <limits.h>), but it's not a huge deal. >> >> I think if it were to be added, it would make sense to have a new header >> and to include functions for swapping endianness or otherwise >> manipulating data in endianness-specific ways. When code needs to know >> the endianness of a platform, it is often in order to create such >> functions - so having them in the header file would be convenient. The >> challenge would be for targets that are not pure little-endian or pure >> big-endian. I expect this would need to be an optional feature. > > I believe I've advocated for such functions. If such functions were > standard, an implementation could process them as efficient intrinsics > much more easily than it could recognize all of the combinations of > shifts and other operations user code might employ to do the same thing. >
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-01 14:40 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-01 14:55 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-02 21:05 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-03 01:18 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 01:03 +0000
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 22:37 -0800
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 01:23 +0000
Re: Compiling and linking code from different places in the file system "James R. Kuyper" <jameskuyper@verizon.net> - 2018-03-01 11:11 -0500
Re: Compiling and linking code from different places in the file system "James R. Kuyper" <jameskuyper@verizon.net> - 2018-03-01 13:51 -0500
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 11:02 -0800
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-03 09:48 +0000
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 04:06 -0800
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 05:24 -0800
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 06:43 -0800
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-06 13:51 -0800
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-01 22:46 +0000
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 15:27 -0800
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-03 12:25 +0000
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 04:53 -0800
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-03 15:32 +0000
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 08:02 -0800
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-04 07:52 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-04 08:43 +0000
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-05 07:58 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-06 21:37 +0000
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-07 21:02 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-05 15:29 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 04:54 +0000
Re: Compiling and linking code from different places in the file system Robert Wessel <robertwessel2@yahoo.com> - 2018-03-07 00:33 -0600
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 09:55 +0000
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-04 07:39 +0000
Re: Compiling and linking code from different places in the file system Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-03-07 05:00 -0800
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-07 14:09 +0000
Re: Compiling and linking code from different places in the file system Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-07 14:26 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-07 16:35 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-07 09:32 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-07 10:11 -0800
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-07 11:12 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-07 12:01 -0800
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-07 15:43 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-07 19:18 -0800
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-08 09:59 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 10:28 -0800
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-08 13:36 -0800
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-08 21:47 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-08 15:03 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-09 09:59 +0100
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 10:33 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-09 12:27 -0800
Re: Compiling and linking code from different places in the file system scott@slp53.sl.home (Scott Lurndal) - 2018-03-09 20:48 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 13:31 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-10 18:31 +0100
Re: Compiling and linking code from different places in the file system Robert Wessel <robertwessel2@yahoo.com> - 2018-03-10 13:22 -0600
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-10 19:15 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 13:28 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-09 14:13 -0800
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 14:45 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-10 17:39 +0100
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-10 19:00 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 08:26 -0700
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-12 17:06 +0100
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 10:23 -0700
Re: Compiling and linking code from different places in the file system scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 18:42 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 12:20 -0700
Re: Compiling and linking code from different places in the file system scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 20:27 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 14:12 -0700
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-13 11:12 +0100
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-12 09:23 -0700
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 10:38 -0700
Re: Compiling and linking code from different places in the file system David Kleinecke <dkleinecke@gmail.com> - 2018-03-12 11:41 -0700
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 12:10 -0700
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 12:09 -0800
Re: Compiling and linking code from different places in the file system scott@slp53.sl.home (Scott Lurndal) - 2018-03-09 20:46 +0000
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-10 18:35 +0100
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 08:54 -0700
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-13 08:39 +0100
Re: Compiling and linking code from different places in the file system Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-17 11:03 -0700
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-11 07:37 +0000
Re: Compiling and linking code from different places in the file system David Kleinecke <dkleinecke@gmail.com> - 2018-03-11 14:22 -0700
Re: Compiling and linking code from different places in the file system Spiros Bousbouras <spibou@gmail.com> - 2018-03-11 21:48 +0000
Re: Compiling and linking code from different places in the file system David Kleinecke <dkleinecke@gmail.com> - 2018-03-11 17:50 -0700
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-11 15:54 -0700
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 09:38 -0700
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-08 10:48 +0100
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 09:58 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-08 22:03 +0100
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 13:55 -0800
Re: Compiling and linking code from different places in the file system Spiros Bousbouras <spibou@gmail.com> - 2018-03-08 22:38 +0000
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 15:03 -0800
Re: Compiling and linking code from different places in the file system Spiros Bousbouras <spibou@gmail.com> - 2018-03-08 23:15 +0000
Re: Compiling and linking code from different places in the file system Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-17 10:44 -0700
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 03:47 -0700
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-09 10:10 +0100
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-09 10:10 -0800
Re: Compiling and linking code from different places in the file system jameskuyper@verizon.net - 2018-03-08 14:21 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 15:10 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-09 10:13 +0100
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-09 10:10 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-08 10:28 +0100
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-08 10:28 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-08 22:17 +0100
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 13:26 -0800
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 13:39 +0100
csiph-web