C Language, C portability [slightly OT]

C portability [slightly OT]

Author	Message
Tom St Deni #1 / 27	C portability [slightly OT] Ok I admit this is not a post about C99 directly so please don't post "this isn't a c99 post". My question is exactly this: 1. If you force a char to be 8-bits 2. If you force the bits loaded into a char to be the same way as a x86 [but not into dwords, I assume endianess of bytes is different] 3. If you force either "long long" or "__int64" to be capable of holding a 64-bit value 4. If you force the charset to be ASCII i.e 'a' is 65 [or whatever it is...] like char a = 'a' is the same as char a = 65; How many platforms will conform? Afaik all x86 clones, all 68K clones and the Alpha series [compaq] will conform. Are these restrictions to imposing on modern computer users? Tom
Sun, 27 Jun 2004 23:59:12 GMT

Simon Bibe #2 / 27	C portability [slightly OT] Quote: > Ok I admit this is not a post about C99 directly so please don't > post "this isn't a c99 post". > My question is exactly this: > 1. If you force a char to be 8-bits char must be at least 8 bits. The vast majority of hosted implementations have exactly 8-bit chars. Many embedded systems and mainframes do not. Quote: > 2. If you force the bits loaded into a char to be the same way > as a x86 [but not into dwords, I assume endianess of bytes is > different] You mean, char is signed, and uses an 8-bit two's complement representation with no padding bits? In that case, yes, most will conform. Quote: > 3. If you force either "long long" or "__int64" to be capable > of holding a 64-bit value In a C99 implementation, long long must be able to hold a 64-bit value including sign bit (that is, at least from -9223372036854775807 to 9223372036854775807). The second requirement is rather simple to emulate: typedef long long __int64; Quote: > 4. If you force the charset to be ASCII i.e 'a' is 65 [or > whatever it is...] like char a = 'a' is the same as > char a = 65; ITYM 'A', because 'a' is 97 in ASCII. Again, most platforms do conform to ASCII. It is those at the smallest and largest ends of the scale which may use propietary encodings (or EBCDIC). I don't expect to ever run my code on a non-ASCII machine, but I generally code such that it's ANSI/ISO compliant and does not rely on implementation-specific behaviour wherever possible. Quote: > Afaik all x86 clones, all 68K clones and the Alpha series [compaq] > will conform. Conformance is by no means restricted to the processor type! An implementation can add any amount of emulation of things that aren't natively available. On many of the above processors that applies to 64-bit arithmetic. And, there is nothing stopping a conforming implementation on x86 processors to use 16-bit chars. Quote: > Are these restrictions to imposing on modern computer users? ^ missing 'o'. Sorry, it irks me. It really depends on who your target audience is. Many C programmers target embedded systems where char, int, long may all be the same size. Many mainframes and supercomputers also fail items 1, 2 and 4 above. You can expect modern PC, Unix, Mac, etc systems to conform to your requirements above, assuming you have a compiler that supports `long long`. -- Simon.
Mon, 28 Jun 2004 01:19:23 GMT

Tom St Deni #3 / 27	C portability [slightly OT] Quote: > > Ok I admit this is not a post about C99 directly so please don't > > post "this isn't a c99 post". > > My question is exactly this: > > 1. If you force a char to be 8-bits > char must be at least 8 bits. The vast majority of hosted implementations > have exactly 8-bit chars. Many embedded systems and mainframes do not. This isn't always true. Most compilers for the Z80, 680x and 8051 series assume "int" is 16-bits and "char" is 8-bits. I agree that a platform could have 91-bit chars, etc... Quote: > > 2. If you force the bits loaded into a char to be the same way > > as a x86 [but not into dwords, I assume endianess of bytes is > > different] > You mean, char is signed, and uses an 8-bit two's complement representation > with no padding bits? > In that case, yes, most will conform. > > 3. If you force either "long long" or "__int64" to be capable > > of holding a 64-bit value > In a C99 implementation, long long must be able to hold a 64-bit value > including sign bit > (that is, at least from -9223372036854775807 to 9223372036854775807). > The second requirement is rather simple to emulate: > typedef long long __int64; I meant have either, but thanks. Quote: > > 4. If you force the charset to be ASCII i.e 'a' is 65 [or > > whatever it is...] like char a = 'a' is the same as > > char a = 65; > ITYM 'A', because 'a' is 97 in ASCII. Again, most platforms do conform to > ASCII. It is those at the smallest and largest ends of the scale which may > use propietary encodings (or EBCDIC). > I don't expect to ever run my code on a non-ASCII machine, but I generally > code such that it's ANSI/ISO compliant and does not rely on > implementation-specific behaviour wherever possible. Hmm, ok so I think I will change the char constants to numerical values. - Hide quoted text - - Show quoted text - Quote: > > Afaik all x86 clones, all 68K clones and the Alpha series [compaq] > > will conform. > Conformance is by no means restricted to the processor type! An > implementation can add any amount of emulation of things that aren't > natively available. On many of the above processors that applies to 64-bit > arithmetic. And, there is nothing stopping a conforming implementation on > x86 processors to use 16-bit chars. > > Are these restrictions to imposing on modern computer users? > ^ missing 'o'. Sorry, it irks me. > It really depends on who your target audience is. Many C programmers target > embedded systems where char, int, long may all be the same size. Many > mainframes and supercomputers also fail items 1, 2 and 4 above. > You can expect modern PC, Unix, Mac, etc systems to conform to your > requirements above, assuming you have a compiler that supports `long long`. Ok thanks. I mainly want to know if I make the above assumptions (minus the 'A' == 65 which I will change) if my library will be applicable to a wide range of platforms. [email me if you want to know about my lib, I don't want to plug it here, basically its a crypto library...] Tom
Mon, 28 Jun 2004 01:24:37 GMT

Richard Heathfiel #4 / 27	C portability [slightly OT] Quote: > Ok I admit this is not a post about C99 directly so please don't post "this > isn't a c99 post". > My question is exactly this: > 1. If you force a char to be 8-bits > 2. If you force the bits loaded into a char to be the same way as a x86 > [but not into dwords, I assume endianess of bytes is different] > 3. If you force either "long long" or "__int64" to be capable of holding a > 64-bit value > 4. If you force the charset to be ASCII i.e 'a' is 65 [or whatever it > is...] like char a = 'a' is the same as char a = 65; ( Just a nit: in ASCII, 'A' is 65. 'a' is 97. ) Quote: > How many platforms will conform? Platforms don't conform. Implementations do. Quote: > Afaik all x86 clones, all 68K clones and the Alpha series [compaq] will > conform. > Are these restrictions to imposing on modern computer users? Yes. You just blew away quite a few of the implementations typically used for mainframes and DSPs. (Also, by insisting on long long, you blew away almost every other implementation in existence! But we covered that already elsenet.) Come on, Tom - it's not /that/ hard to write portable code. :-) -- "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html K&R answers, C books, etc: http://users.powernet.co.uk/eton
Mon, 28 Jun 2004 00:34:26 GMT

Tom St Deni #5 / 27	C portability [slightly OT] Quote: > > Ok I admit this is not a post about C99 directly so please don't post "this > > isn't a c99 post". > > My question is exactly this: > > 1. If you force a char to be 8-bits > > 2. If you force the bits loaded into a char to be the same way as a x86 > > [but not into dwords, I assume endianess of bytes is different] > > 3. If you force either "long long" or "__int64" to be capable of holding a > > 64-bit value > > 4. If you force the charset to be ASCII i.e 'a' is 65 [or whatever it > > is...] like char a = 'a' is the same as char a = 65; > ( Just a nit: in ASCII, 'A' is 65. 'a' is 97. ) > > How many platforms will conform? > Platforms don't conform. Implementations do. > > Afaik all x86 clones, all 68K clones and the Alpha series [compaq] will > > conform. > > Are these restrictions to imposing on modern computer users? > Yes. You just blew away quite a few of the implementations typically > used for mainframes and DSPs. (Also, by insisting on long long, you blew > away almost every other implementation in existence! But we covered that > already elsenet.) > Come on, Tom - it's not /that/ hard to write portable code. :-) It is if you require a comforming compiler. Also I make silly assumptions like char == 8-bits and bits loaded in order 01234567. These are just practicality issues. The code in question compiles fine on several very popular platforms. Its just too hard to comform to every possible configuration. For example, how do you portability store 0x55, 0x44, 0x33, 0x22 in four consecutive 8-bit allocations in memory [in order as well]. Tom
Mon, 28 Jun 2004 01:35:06 GMT

Mike Wahle #6 / 27	C portability [slightly OT] Quote: > > > Ok I admit this is not a post about C99 directly so please don't post > "this > > > isn't a c99 post". > > > My question is exactly this: > > > 1. If you force a char to be 8-bits > > > 2. If you force the bits loaded into a char to be the same way as a x86 > > > [but not into dwords, I assume endianess of bytes is different] > > > 3. If you force either "long long" or "__int64" to be capable of > holding a > > > 64-bit value > > > 4. If you force the charset to be ASCII i.e 'a' is 65 [or whatever it > > > is...] like char a = 'a' is the same as char a = 65; > > ( Just a nit: in ASCII, 'A' is 65. 'a' is 97. ) > > > How many platforms will conform? > > Platforms don't conform. Implementations do. > > > Afaik all x86 clones, all 68K clones and the Alpha series [compaq] will > > > conform. > > > Are these restrictions to imposing on modern computer users? > > Yes. You just blew away quite a few of the implementations typically > > used for mainframes and DSPs. (Also, by insisting on long long, you blew > > away almost every other implementation in existence! But we covered that > > already elsenet.) > > Come on, Tom - it's not /that/ hard to write portable code. :-) > It is if you require a comforming compiler. > Also I make silly assumptions like > char == 8-bits > and bits loaded in order 01234567. > These are just practicality issues. The code in question compiles fine on > several very popular platforms. > Its just too hard to comform to every possible configuration. For example, > how do you portability store 0x55, 0x44, 0x33, 0x22 in four consecutive > 8-bit allocations in memory [in order as well]. Sounds to me like you're asking how to force a machine whose bytes are greater than eight bits in size to be eight bits. IMO you're asking how to change the hardware (or at least firmware) via a C program. I don't think it's possible. -Mike
Mon, 28 Jun 2004 02:57:49 GMT

Tom St Deni #7 / 27	C portability [slightly OT] Quote: > Sounds to me like you're asking how to force a machine > whose bytes are greater than eight bits in size to > be eight bits. IMO you're asking how to change the > hardware (or at least firmware) via a C program. > I don't think it's possible. You're telling me there is no portable way for a machine with "char != 8 bits" to talk to a HTTP [for example] server? Ok, well I guess from now on my definition of "portable" means "a common sense practical virtually everywhere platform". Thanks for the info. Tom
Mon, 28 Jun 2004 02:47:51 GMT

Richard Heathfiel #8 / 27	C portability [slightly OT] Quote: > Its just too hard to comform to every possible configuration. For example, > how do you portability store 0x55, 0x44, 0x33, 0x22 in four consecutive > 8-bit allocations in memory [in order as well]. First of all, I can't store anything in an allocation. I can only store values in objects. So I'll have to guess what you mean. If you want those values stored in four consecutive objects, you can do this: unsigned char bitmap[4] = {0x55, 0x44, 0x33, 0x22}; If, however, you want them to be guaranteed to be stored in 32 consecutive bits, you can do this: unsigned long tomsbits = 0x55443322; If you are thinking now about endianism, just remember that you can get the values out in the right order like this, irrespective of endianism or how many bits there are in a byte: unsigned long firstpart = (tomsbits & 0xFF000000) >> 24; unsigned long secondpart = (tomsbits & 0xFF0000 ) >> 16; unsigned long thirdpart = (tomsbits & 0xFF00 ) >> 8; unsigned long fourthpart = tomsbits & 0xFF; -- "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html K&R answers, C books, etc: http://users.powernet.co.uk/eton
Mon, 28 Jun 2004 02:25:45 GMT

Tom St Deni #9 / 27	C portability [slightly OT] Quote: > > Its just too hard to comform to every possible configuration. For example, > > how do you portability store 0x55, 0x44, 0x33, 0x22 in four consecutive > > 8-bit allocations in memory [in order as well]. > First of all, I can't store anything in an allocation. I can only store > values in objects. So I'll have to guess what you mean. > If you want those values stored in four consecutive objects, you can do > this: > unsigned char bitmap[4] = {0x55, 0x44, 0x33, 0x22}; > If, however, you want them to be guaranteed to be stored in 32 > consecutive bits, you can do this: > unsigned long tomsbits = 0x55443322; Yeah, but how do I send those bytes from point A to point B? Quote: > If you are thinking now about endianism, just remember that you can get > the values out in the right order like this, irrespective of endianism > or how many bits there are in a byte: > unsigned long firstpart = (tomsbits & 0xFF000000) >> 24; > unsigned long secondpart = (tomsbits & 0xFF0000 ) >> 16; > unsigned long thirdpart = (tomsbits & 0xFF00 ) >> 8; > unsigned long fourthpart = tomsbits & 0xFF; Ok, lets put this in context. I want to put the values in consectutive 8-bit units of memory to send over [say] TCP/IP. How do I do that in portable ISO C? Tom
Mon, 28 Jun 2004 02:55:54 GMT

Simon Bibe #10 / 27	C portability [slightly OT] Quote: > Ok, lets put this in context. > I want to put the values in consectutive 8-bit units of memory > to send over [say] TCP/IP. Why do they need to be in consecutive 8-bit units of memory? Many platforms do not have consecutive 8-bit units of memory. I think you just want them in consecutive bytes. Quote: > How do I do that in portable ISO C? unsigned long tomsbits = 0x55443322; unsigned char consecutive[4]; consecutive[0] = (tomsbits & 0xFF000000) >> 24; consecutive[1] = (tomsbits & 0xFF0000 ) >> 16; consecutive[2] = (tomsbits & 0xFF00 ) >> 8; consecutive[3] = tomsbits & 0xFF; Then send consecutive to whatever function expects four bytes of memory to send over TCP/IP. (You can modify the array indexes to 3, 2, 1, 0 or whatever, if that better suits the endianness the other party expects.) -- Simon.
Mon, 28 Jun 2004 03:09:20 GMT

Tom St Deni #11 / 27	C portability [slightly OT] Quote: > > Ok, lets put this in context. > > I want to put the values in consectutive 8-bit units of memory > > to send over [say] TCP/IP. > Why do they need to be in consecutive 8-bit units of memory? > Many platforms do not have consecutive 8-bit units of memory. Such as? I consider most platforms x86, 68k or Alpha derivatives. Quote: > I think you just want them in consecutive bytes. > > How do I do that in portable ISO C? > unsigned long tomsbits = 0x55443322; > unsigned char consecutive[4]; > consecutive[0] = (tomsbits & 0xFF000000) >> 24; > consecutive[1] = (tomsbits & 0xFF0000 ) >> 16; > consecutive[2] = (tomsbits & 0xFF00 ) >> 8; > consecutive[3] = tomsbits & 0xFF; > Then send consecutive to whatever function expects four bytes of memory to > send over TCP/IP. Arrg... You know what... {filter} it. Big first page in my manual will say "char == 8 bits". I really can't stand this shit. "char == 9 bits" has NO practical value in a modern widely deployed computer. You guys point out estoteric embedded systems or mainframes, but 99% of the people who will use my code are on home PCs [i.e x86 systems, or 68k systems]. So if someone on a PIC [etc] microcontroller can't use my crypto lib [which wouldn't fit in the memory of a typical PIC anyways] than tuff. Tom
Mon, 28 Jun 2004 03:15:39 GMT

Richard Heathfiel #12 / 27	C portability [slightly OT] Quote: > > Sounds to me like you're asking how to force a machine > > whose bytes are greater than eight bits in size to > > be eight bits. IMO you're asking how to change the > > hardware (or at least firmware) via a C program. > > I don't think it's possible. > You're telling me there is no portable way for a machine with "char != 8 > bits" to talk to a HTTP [for example] server? There's no portable way for /any/ program written in /any/ programming language to talk to an HTTP server. Quote: > Ok, well I guess from now on my definition of "portable" means "a common > sense practical virtually everywhere platform". <shrug> That's a reasonable attempt at a definition of "portable", provided your understanding of "virtually everywhere" is sufficiently broad. Generally, I would consider a program to be /sufficiently/ portable if: 1) it does not invoke undefined behaviour; 2) when it invokes unspecified behaviour, this doesn't matter to the program; 3) when it invokes implementation-defined behaviour, this doesn't adversely affect the behaviour of the program. Trivial example: #include <stdio.h> #include <limits.h> int main(void) { printf("Biggest int on this implementation is %d.\n", INT_MAX); return 0; Quote: } This program will give different results on different implementations, but I hope it's clear that this doesn't matter from the perspective of the program's purpose. So, as far as I'm concerned, it's a portable program. -- "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html K&R answers, C books, etc: http://users.powernet.co.uk/eton
Mon, 28 Jun 2004 03:36:53 GMT

Simon Bibe #13 / 27	C portability [slightly OT] Quote: > > Many platforms do not have consecutive 8-bit units of memory. > Such as? I don't think you need the examples reiterated. Quote: > I consider most platforms x86, 68k or Alpha derivatives. I said "many", not "most". In comp.lang.c we discuss the C programming using the ISO C standard, including all implementations it allows. You are free to write programs that are portable only to systems on which CHAR_BIT==8, but expect criticism if ever you try to discuss them on c.l.c. [snip] Quote: > Arrg... > You know what... {filter} it. Big first page in my manual will > say "char == 8 bits". Why not add in the code: #if CHAR_BIT != 8 #error This program is designed to operate only on implementations where CHAR_BIT == 8 #endif Quote: > I really can't stand this shit. "char == 9 bits" has NO practical value in > a modern widely deployed computer. I agree. A CHAR_BIT of 16 or 32 bits simplifies things for embedded systems, and is necessary on some dodgy old mainframe systems which were designed before C became widespread. But in c.l.c we try to design code that will run on any implementation that conforms to the C standard. Quote: > You guys point out estoteric embedded systems or mainframes, but 99% of the > people who will use my code are on home PCs [i.e x86 systems, or 68k > systems]. Probably. But you'd be surprised what people try to do. -- Simon.
Mon, 28 Jun 2004 03:34:53 GMT

Tom St Deni #14 / 27	C portability [slightly OT] Quote: > > > Sounds to me like you're asking how to force a machine > > > whose bytes are greater than eight bits in size to > > > be eight bits. IMO you're asking how to change the > > > hardware (or at least firmware) via a C program. > > > I don't think it's possible. > > You're telling me there is no portable way for a machine with "char != 8 > > bits" to talk to a HTTP [for example] server? > There's no portable way for /any/ program written in /any/ programming > language to talk to an HTTP server. Fair enough. Quote: > > Ok, well I guess from now on my definition of "portable" means "a common > > sense practical virtually everywhere platform". > <shrug> That's a reasonable attempt at a definition of "portable", > provided your understanding of "virtually everywhere" is sufficiently > broad. > Generally, I would consider a program to be /sufficiently/ portable if: > 1) it does not invoke undefined behaviour; > 2) when it invokes unspecified behaviour, this doesn't matter to the > program; > 3) when it invokes implementation-defined behaviour, this doesn't > adversely affect the behaviour of the program. > Trivial example: > #include <stdio.h> > #include <limits.h> > int main(void) > { > printf("Biggest int on this implementation is %d.\n", INT_MAX); > return 0; > } > This program will give different results on different implementations, > but I hope it's clear that this doesn't matter from the perspective of > the program's purpose. So, as far as I'm concerned, it's a portable > program. So to get respect from a group I should code my stuff for every imaginable platform even ones where the library doesn't apply or not likely to be used in the first place? This also horribly slows down all the code. I have todo "& 255" whenever I touch a byte [primary example], to me anyone using a platform that cannot work on a byte unit [and requires byte unit arithmetic] is cheating themselves. Tom
Mon, 28 Jun 2004 03:39:03 GMT

Ben Pfaf #15 / 27	C portability [slightly OT] Quote: > > You're telling me there is no portable way for a machine with "char != 8 > > bits" to talk to a HTTP [for example] server? > There's no portable way for /any/ program written in /any/ programming > language to talk to an HTTP server. I'm not sure what criteria you're applying for portability here. I would consider CGI a portable means for a C program to talk to an HTTP server, because it works without using any language extensions. Also, I think you're overgeneralizing: I'm sure there are languages that have built-in means to talk to HTTP servers, so programs written in those languages for talking to HTTP servers are as portable as the languages themselves.
Mon, 28 Jun 2004 03:37:58 GMT

Page 1 of 2

[ 27 post ]

Go to page: [1] [2]