Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #127173 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2018-03-01 14:40 +0000 |
| Last post | 2018-03-14 13:39 +0100 |
| Articles | 3 on this page of 103 — 17 participants |
Back to article view | Back to comp.lang.c
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
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-08 22:17 +0100 |
| Message-ID | <p7s98t$hs4$1@dont-email.me> |
| In reply to | #127490 |
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. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-08 13:26 -0800 |
| Message-ID | <lna7vidzsh.fsf@kst-u.example.com> |
| In reply to | #127490 |
supercat@casperkitty.com writes:
> 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". Is there any
> reason why a 64-bit processor system should not be able to use code written
> for a smaller micro?
Code not designed to be portable might fail, and there are sometimes
good reasons to write non-portable code. Code written to be portable,
if that's done successfully, should work on either 32-bit or 64-bit
systems.
Code written to assume that long is exactly 32 bits, **which is what you
suggested upthread**, would obviously fail on an implementation where
long is 64 bits.
Did you mean to suggest that code should assume long is exactly 32 bits?
I've restated that interpretation of your words several times, and you
haven't corrected it.
[...]
> 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.
"%d" is for int, and for narrower types that promote to int. "%ld" with
a 32-bit argument has undefined behavior, and will likely fail, on a
system where long is 64 bits, and as you know such systems are common.
Here's a radical idea: Use the right format for the type you're
printing. If you're not sure what it is, convert the argument to a type
for which you know the right format. There is no other correct
solution, unless you design a new output system.
> 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.
It works. Yes, omitting the cast can cause problems.
>> > 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.
int32_t and uint32_t exist. You almost certainly don't need to reinvent
them. If you do, that work has already been done (I provided a link
upthread).
[...]
> 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.
You want the standard to define a way, probably using predefined macros,
for an application to find the endianess (big-endian, little-endian, or
other) of the current platform.
Does anything more than that need to be said?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
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"
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2018-03-14 13:39 +0100 |
| Message-ID | <m2tvtirfui.fsf@despina.home> |
| In reply to | #127173 |
James Harris <james.harris.1@gmail.com> writes: > Irrespective of whether the build is being done under Unix or Windows > or whatever OS, what's a good way to specify the include folders > (e.g. on Unix those folder names which have to appear after -I on the > compiler command line) so that its easy enough even in a big project > to generate the necessary compile commands? So you know about the -I argument. Now to answer you question, you have to know what build system you are using. This is doable easily enough in makefiles. In more sophisticated cases, I would advise to use scons. -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.c
csiph-web