This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | → | Archive 5 |
376 is pronounced as "Dreihundertsechsundsiebzig", i.e. "three hundred six-and-seventy". So, whats the difference to three-hundred-and-seven-teen?
We have this endianness scheme in old-style Norwegian counting as well. The "new counting style" (similar to the English way) became an official policy in Norway right after WWII, but we still hang on to the old way. Serves to show how difficult it is to change people's daily language by government decree. :-) -- Wernher 05:52, 18 Apr 2005 (UTC)
It's not true that English is big-endian. In English, a number followed by a smaller number implies addition (eg. fifty five = 50+5) while a number followed by a larger number implies multiplication (eg. three hundred = 3×100). Thus, "two thousand five hundred eighty four" is 2×1000+5×100+80+4 = 2584. -- Doradus 03:21, 29 December 2005 (UTC)
No. Word order never implies multiplication in English. The reason "three hundred" means 300 is that "hundred" is a place marker (like the "-ty" suffix), not a number. To represent 100, except in special contexts, you have to say "one hundred" or "a hundred." Meanwhile, you can't say "three fifty" to mean 3*50=150--in fact, "three fifty" means 350 (or 3.50, 3 hours 50 minutes, etc.--but notice that even these examples are big-endian).
Violating big-endian order in English is possible, but it always requires extra verbiage, and usually sounds archaic or strange. The best example I can think of is "four and twenty" for 24. Falcotron 04:15, 18 June 2006 (UTC)
Lemuel Gulliver's the name of the character, isn't it (as opposed to Swift's pen name)?
I changed the example 0xDEADBEEF since it might give readers the mistaken impression that hex digits are the same as letters and that texts are stored on computers as hex digits. AxelBoldt 16:42, 17 Mar 2004 (UTC)
Does endianness also affect the storing of texts? I.e., is the text 'ABCD' stored as ASCII 0x44434241 on little endian machines? AxelBoldt 16:49, 17 Mar 2004 (UTC)
Ok, so if endianness does not affect the storing of ASCII text (1 byte=1 char), what exactly is the NUXI problem? I don't understand. AxelBoldt 13:19, 20 Mar 2004 (UTC)
This site gives a good answer. I think this kind of things happen when you are dealing with a magic number at the beginning of binary files. For example, PNG files starts a four-byte string containing PNG or something (I believe). Then it matters if you are using a big-enddian or little-enddian. True, the article should be more clear about this. -- Taku 01:04, Mar 21, 2004 (UTC)
This is backwards, since a dictionary is not a list of correct words. Correct words go into dictionaries, I must agree, but that doesn't mean that wrong words do not enter dictionaries or that no correct words are ommitted from dictionaries. Kjoonlee 10:02, 2005 Feb 1 (UTC)
I've removed the above text because it applies just as well to big-endian machines. I've coded just such a manipulation many times for both types of endianness. In many cases the code need not differ at all. In other cases the code differs but as duals of each other; neither is more complicated than the other. - R. S. Shaw 04:27, 11 Mar 2005 (UTC)
I added a little section about endians in the various date formats, because it's a nice easy example for us dummies. If it's wrong, feel free to kick my ass and remove it. Or just remove it. Proto 13:17, 6 Apr 2005 (UTC)
Hell, I think it's a stroke of genius. It's a great analogy. Maybe a tad long, but great nonetheless.
Scotto
04:07, 9 November 2005 (UTC)
Do we really need these amateurish nicknames in there? As far as I know, they're not used in a professional context and they make Wikipedia sound silly. Other articles wouldn't use industry-specific slang.
I'd change "Architectures that follow this rule are called big-endian and include Motorola 68000, SPARC and System/370." like this: "Architectures that follow this rule are called big-endian (for "big end first") and include Motorola 68000, SPARC and System/370." i.e. add the parentheses with an explanation.
I think this would make understanding the point even easier, although the example is already pretty clear.
However I don't want to create confusion with the real origin of the term which is explained in the Background section below.
Perhaps it should be placed somewhere else, or in a different wording, but I'd still like to stick the "big end first" somewhere.
Comments?
Krille 11:53, 29 Apr 2005 (UTC)
I would like to suggest the addition of a little-endian alphabetical index for Wikipedia. At the present time, the only alphabetical index for Wikipedia is big-endian. A little-endian index can help a researcher who knows the last letters of a word but not its first letters. Also, it can make it easier to research a set of words with a common ending, for example, "-shire", "-itis", "-osis", "-mania", "-phobia", "-ton", "-ville", "-ide", "-ic acid", and "-ics". If, after this suggestion is considered, it is not implemented, please state the reason(s) on this page. Here is a sample listing:
a aa baa baba samba rumba tuba abaca Inca agenda aloha Himalaya Hunza baobab cab taxicab dab tab buzz abuzz fuzz
Wavelength 22:33, 24 May 2005 (UTC)
An anonymous user made some changes showing System/370, System/390 and z/OS as bi-endian. ( z/OS is an OS; probably meant zSeries.) I'm not that knowledgeable about these, but I'm sure the 370 was pure big endian, so I've reverted the changes for now. Googling this seems a bit hard, but did find this on an IBM site: http://www-128.ibm.com/developerworks/eserver/articles/linux_s390/ which is "Linux for S/390 and zSeries porting hints" and says "zSeries is a big-endian system. Any code that processes byte-oriented data that originated on a little-endian system might need some byte swapping...." so it really does look like Anon's edits were off base. - R. S. Shaw 05:36, 28 May 2005 (UTC)
With the exception of middle-endianness, is big-endianism and little-endianism the same thing as most significant bit (MSB) and least significant bit (LSB) respectively? misternuvistor 21:40, Jun 5, 2005 (UTC)
"IA-64 running Linux"
Bi-endianness is a non-sense since layout can be based either on little-endian format or big-endian format: a bi-endian data is ambiguous. I'd prefer to keep little-endian and big-endian keywords, introducing Byte-Swap in atomic elements. Hence any confusion disappears.
Bertrand Blanc
14:22, 1 September 2006 (UTC)
The article now says, "The written system of arabic numerals is used world-wide and is such that the most significant digits are always written to the left of the less significant ones. In languages that write text left-to-right, this system is therefore big-endian, in languages that write right-to-left, this numeral system is little-endian."
Numbers written in arabic numerals are big-endian, because the language of mathematics itself is left-to-right. In Hebrew, if a multi-digit number appears in the middle of a sentence, it is written and read left-to-right, just as in English. In Hebrew, numbers are not little-endian. Numbers, and all of mathematics, are left-to-right.
Biblical Hebrew sometimes used little-endian word order for numbers, but in modern Hebrew, big-endian word order is used exclusively, except for poetic use analogous to "Four and twenty blackbirds baked in a pie."
Thank you, R. S. Shaw, but I think you have missed the point. One must read each string in the order it was intended to be read. English words are intended to be read left to right. Hebrew words are intended to be read right to left. Numbers, arithmetic, and algebraic expressions are intended to be read left to right. These are all true even when embedded in each other's domains. If a Hebrew text discusses the French expression "joie de vivre," it might embed these words in ordinary left-to-right spelling in the middle of a Hebrew sentence. One would begin the Hebrew sentence at the right, but when one comes to the French words one would jump leftward and read "joie de vivre" left to right, and then continue reading Hebrew right to left, just to the left of "joie."
Now suppose you wanted to translate this sentence into Hebrew: I have 31 – 2 = 29 oranges. Transliterated first, that's "Yesh li 31 – 2 = 29 tapuzim." In Hebrew:
יש לי 31 – 2 = 29 תפוזים.
The entire mathematical expression 31 – 2 = 29 is read left to right.
Or consider decimal numbers, for example, 3.14159. Do you really think anyone, even someone whose only written language is Hebrew, could possibly read that number right to left? I don't think so. I think everyone in the world, whether a reader of a left-to-right language or a right-to-left language, reads that as "three point one four one five nine" in the words of their language.
In conclusion, in Hebrew, numbers are read left to right, and therefore are big-endian.
I must be missing something here. What relevance could Hebrew possibly have to Arabic numerals? Hebrew is one of the few languages in the world which does NOT use the Arabic numbering system. In any right-to-left language which uses Arabic numerals, such as Arabic itself, they are little-endian, in any left-to-right language, they are big-endian. Hebrew uses a completely different numbering system as evidenced by the flabbergastingly obvious point that it uses Hebrew letters, not Arabic numerals. I mean, Jesus H, fellows. I'm changing the article.
Persuter 21:36, 24 Aug 2010 (UTC)
I think I'll settle this argument.
Let's say pi = 3.14
Now, is that big-endian or little-endian?
If you read it left-to-right it's big-endian; if you read it right-to-left it's little-endian. There is no practical difference between the two.
Likewise, pi = 41.3 is left-to-right little-endian or right-to-left big-endian.
Get my point? I think I get both of yours.
It all depends on which way you read it. I see it as big-endian, as most of the people out there probably do, but there are probably still a small few who see it as little-endian.
Tada. -- Ihope127 19:28, 23 July 2005 (UTC)
I looked at both the article and the long-winded "explanation" above for the current text (Jan 10, 2006) which states that the Indic-Arabic system of digits is always bigendian. That is totally and utter hogwash, as Tada above eminently illustrates. Embedded in a right-to-left stream, Indic-Arabic digits are clearly littleendian. If one chooses to interrupt the order and read the digits left-to-right, then of course it's bigendian -- but that's not a property of the digits! The fact that Hebrew (the example used) may deal with numbers in a bigendian fashion has nothing to do with it. Contrapositively, Danish is an example of a language written with a left-to-right script (Latin) which deals with numbers in a littleendian fashion -- the number 82 is read as to og firs (two-and-eighty) -- a littleendian treatment, but according to the article's argument, that would imply Indic-Arabic letters are always littleendian!
I do intend to change this, obviously. The argument is ridiculous.
-- User:HpaScalar 10 Jan 2006
103
|
102
|
101
|
100
|
||
...
|
1D
|
2C
|
3B
|
4A
|
...
|
A spelling question: is "Big-endian" spelled with or without the hypen? The article has mostly with, but a few without, for example, in the "Portability Issues" section, we have:
"... if the data are stored using big endian integers ..."
and in the "Discussion, background, etymology" section:
" ... The spoken numeral system in English is big endian (with minor exceptions ..."
These are the only two such examples I find, the rest are more like:
"... In a consistently big-endian architecture ..."
I suspect the hyphen should be required and the first two examples should be corrected. Yes?
Currently the example code is not legal C, or even C++. (Neither has a "boolean" type for one thing)
The lead-in to the example was recently changed to assert that the code assumes that char is 1 byte. The code does not have to assume this; char is defined to be 1 byte. (A byte is not necessarily defined to be an octet, but the code doesn't make any assumptions about that.) You could read the ANSI and ISO C standards (89/90 and 99), the C++ standards, and the manuals for every common pre-standard compiler if you wanted. Or just see http://www.parashift.com/c++-faq-lite/intrinsic-types.html (which is C++, granted, but the same is true in C).
Note that int > char is still an assumption. For example, an embedded system or DSP that couldn't access anything smaller than a word efficiently (or at all) might define char, short, and int to all be one machine word, 16 bits. The code would not work on such a compiler. Falcotron 05:41, 27 June 2006 (UTC)
The most recent change to the example improves things in two ways:
But:
True, the code could still be wrong if, e.g., sizeof(intmax_t) > sizeof(long) == sizeof(char). But this could not have any effect on portable C89 code, and it's not detectable with portable C89 code. If you're using C99 (or a compiler with similar extensions), just use intmax_t (or the largest type you intend to use) in place of long in the code, and it'll work fine.
Also, I thought it might be a good idea to point out that middle-endian systems will be incorrectly detected as little-endian, rather than just saying that they won't be detected.
So, I reverted the code and fixed the preceding discussion. I also added a short discussion above about systems with all types the same size further up. And I fixed some minor typos and grammatical errors.
I'm not sure mention of any of this extra complexity with 32-bit-byte systems and so on needs to be in the article at all--but I'm guessing that if it's not there, someone will add something overly complicated again, so I tried to come up with something correct that fits in a single parenthesized sentence. -- Falcotron 04:22, 25 July 2006 (UTC)
int bigendian() { long i = 1; const char *p = (const char *) &i; return p[0] != 1; /* Lowest address doesn't contain least significant byte */ }
I added a one-line mention of the Berkely sockets conversion functions (htonl and friends) since Wikipedia had no hits for them. I'm adding a redirect from those functions to this article: is that appropriate, or should I write a new "endianness conversion function" stub or something? -- Victor Lighthill 20:10, 17 November 2005 (UTC)
As a reader, I'd prefer to have all topics around Endianness located in one place. Conversion functions are furthermore highly relevant to allow Endian heterogeneous systems to communicate. I ended up with following comversion functions (Z/Z' is element size, ZS/ZS' is atomic element unit, l is little-endian, b is big-endian). Is it aligned with your study? Bblanc 12:21, 29 August 2006 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | → | Archive 5 |
376 is pronounced as "Dreihundertsechsundsiebzig", i.e. "three hundred six-and-seventy". So, whats the difference to three-hundred-and-seven-teen?
We have this endianness scheme in old-style Norwegian counting as well. The "new counting style" (similar to the English way) became an official policy in Norway right after WWII, but we still hang on to the old way. Serves to show how difficult it is to change people's daily language by government decree. :-) -- Wernher 05:52, 18 Apr 2005 (UTC)
It's not true that English is big-endian. In English, a number followed by a smaller number implies addition (eg. fifty five = 50+5) while a number followed by a larger number implies multiplication (eg. three hundred = 3×100). Thus, "two thousand five hundred eighty four" is 2×1000+5×100+80+4 = 2584. -- Doradus 03:21, 29 December 2005 (UTC)
No. Word order never implies multiplication in English. The reason "three hundred" means 300 is that "hundred" is a place marker (like the "-ty" suffix), not a number. To represent 100, except in special contexts, you have to say "one hundred" or "a hundred." Meanwhile, you can't say "three fifty" to mean 3*50=150--in fact, "three fifty" means 350 (or 3.50, 3 hours 50 minutes, etc.--but notice that even these examples are big-endian).
Violating big-endian order in English is possible, but it always requires extra verbiage, and usually sounds archaic or strange. The best example I can think of is "four and twenty" for 24. Falcotron 04:15, 18 June 2006 (UTC)
Lemuel Gulliver's the name of the character, isn't it (as opposed to Swift's pen name)?
I changed the example 0xDEADBEEF since it might give readers the mistaken impression that hex digits are the same as letters and that texts are stored on computers as hex digits. AxelBoldt 16:42, 17 Mar 2004 (UTC)
Does endianness also affect the storing of texts? I.e., is the text 'ABCD' stored as ASCII 0x44434241 on little endian machines? AxelBoldt 16:49, 17 Mar 2004 (UTC)
Ok, so if endianness does not affect the storing of ASCII text (1 byte=1 char), what exactly is the NUXI problem? I don't understand. AxelBoldt 13:19, 20 Mar 2004 (UTC)
This site gives a good answer. I think this kind of things happen when you are dealing with a magic number at the beginning of binary files. For example, PNG files starts a four-byte string containing PNG or something (I believe). Then it matters if you are using a big-enddian or little-enddian. True, the article should be more clear about this. -- Taku 01:04, Mar 21, 2004 (UTC)
This is backwards, since a dictionary is not a list of correct words. Correct words go into dictionaries, I must agree, but that doesn't mean that wrong words do not enter dictionaries or that no correct words are ommitted from dictionaries. Kjoonlee 10:02, 2005 Feb 1 (UTC)
I've removed the above text because it applies just as well to big-endian machines. I've coded just such a manipulation many times for both types of endianness. In many cases the code need not differ at all. In other cases the code differs but as duals of each other; neither is more complicated than the other. - R. S. Shaw 04:27, 11 Mar 2005 (UTC)
I added a little section about endians in the various date formats, because it's a nice easy example for us dummies. If it's wrong, feel free to kick my ass and remove it. Or just remove it. Proto 13:17, 6 Apr 2005 (UTC)
Hell, I think it's a stroke of genius. It's a great analogy. Maybe a tad long, but great nonetheless.
Scotto
04:07, 9 November 2005 (UTC)
Do we really need these amateurish nicknames in there? As far as I know, they're not used in a professional context and they make Wikipedia sound silly. Other articles wouldn't use industry-specific slang.
I'd change "Architectures that follow this rule are called big-endian and include Motorola 68000, SPARC and System/370." like this: "Architectures that follow this rule are called big-endian (for "big end first") and include Motorola 68000, SPARC and System/370." i.e. add the parentheses with an explanation.
I think this would make understanding the point even easier, although the example is already pretty clear.
However I don't want to create confusion with the real origin of the term which is explained in the Background section below.
Perhaps it should be placed somewhere else, or in a different wording, but I'd still like to stick the "big end first" somewhere.
Comments?
Krille 11:53, 29 Apr 2005 (UTC)
I would like to suggest the addition of a little-endian alphabetical index for Wikipedia. At the present time, the only alphabetical index for Wikipedia is big-endian. A little-endian index can help a researcher who knows the last letters of a word but not its first letters. Also, it can make it easier to research a set of words with a common ending, for example, "-shire", "-itis", "-osis", "-mania", "-phobia", "-ton", "-ville", "-ide", "-ic acid", and "-ics". If, after this suggestion is considered, it is not implemented, please state the reason(s) on this page. Here is a sample listing:
a aa baa baba samba rumba tuba abaca Inca agenda aloha Himalaya Hunza baobab cab taxicab dab tab buzz abuzz fuzz
Wavelength 22:33, 24 May 2005 (UTC)
An anonymous user made some changes showing System/370, System/390 and z/OS as bi-endian. ( z/OS is an OS; probably meant zSeries.) I'm not that knowledgeable about these, but I'm sure the 370 was pure big endian, so I've reverted the changes for now. Googling this seems a bit hard, but did find this on an IBM site: http://www-128.ibm.com/developerworks/eserver/articles/linux_s390/ which is "Linux for S/390 and zSeries porting hints" and says "zSeries is a big-endian system. Any code that processes byte-oriented data that originated on a little-endian system might need some byte swapping...." so it really does look like Anon's edits were off base. - R. S. Shaw 05:36, 28 May 2005 (UTC)
With the exception of middle-endianness, is big-endianism and little-endianism the same thing as most significant bit (MSB) and least significant bit (LSB) respectively? misternuvistor 21:40, Jun 5, 2005 (UTC)
"IA-64 running Linux"
Bi-endianness is a non-sense since layout can be based either on little-endian format or big-endian format: a bi-endian data is ambiguous. I'd prefer to keep little-endian and big-endian keywords, introducing Byte-Swap in atomic elements. Hence any confusion disappears.
Bertrand Blanc
14:22, 1 September 2006 (UTC)
The article now says, "The written system of arabic numerals is used world-wide and is such that the most significant digits are always written to the left of the less significant ones. In languages that write text left-to-right, this system is therefore big-endian, in languages that write right-to-left, this numeral system is little-endian."
Numbers written in arabic numerals are big-endian, because the language of mathematics itself is left-to-right. In Hebrew, if a multi-digit number appears in the middle of a sentence, it is written and read left-to-right, just as in English. In Hebrew, numbers are not little-endian. Numbers, and all of mathematics, are left-to-right.
Biblical Hebrew sometimes used little-endian word order for numbers, but in modern Hebrew, big-endian word order is used exclusively, except for poetic use analogous to "Four and twenty blackbirds baked in a pie."
Thank you, R. S. Shaw, but I think you have missed the point. One must read each string in the order it was intended to be read. English words are intended to be read left to right. Hebrew words are intended to be read right to left. Numbers, arithmetic, and algebraic expressions are intended to be read left to right. These are all true even when embedded in each other's domains. If a Hebrew text discusses the French expression "joie de vivre," it might embed these words in ordinary left-to-right spelling in the middle of a Hebrew sentence. One would begin the Hebrew sentence at the right, but when one comes to the French words one would jump leftward and read "joie de vivre" left to right, and then continue reading Hebrew right to left, just to the left of "joie."
Now suppose you wanted to translate this sentence into Hebrew: I have 31 – 2 = 29 oranges. Transliterated first, that's "Yesh li 31 – 2 = 29 tapuzim." In Hebrew:
יש לי 31 – 2 = 29 תפוזים.
The entire mathematical expression 31 – 2 = 29 is read left to right.
Or consider decimal numbers, for example, 3.14159. Do you really think anyone, even someone whose only written language is Hebrew, could possibly read that number right to left? I don't think so. I think everyone in the world, whether a reader of a left-to-right language or a right-to-left language, reads that as "three point one four one five nine" in the words of their language.
In conclusion, in Hebrew, numbers are read left to right, and therefore are big-endian.
I must be missing something here. What relevance could Hebrew possibly have to Arabic numerals? Hebrew is one of the few languages in the world which does NOT use the Arabic numbering system. In any right-to-left language which uses Arabic numerals, such as Arabic itself, they are little-endian, in any left-to-right language, they are big-endian. Hebrew uses a completely different numbering system as evidenced by the flabbergastingly obvious point that it uses Hebrew letters, not Arabic numerals. I mean, Jesus H, fellows. I'm changing the article.
Persuter 21:36, 24 Aug 2010 (UTC)
I think I'll settle this argument.
Let's say pi = 3.14
Now, is that big-endian or little-endian?
If you read it left-to-right it's big-endian; if you read it right-to-left it's little-endian. There is no practical difference between the two.
Likewise, pi = 41.3 is left-to-right little-endian or right-to-left big-endian.
Get my point? I think I get both of yours.
It all depends on which way you read it. I see it as big-endian, as most of the people out there probably do, but there are probably still a small few who see it as little-endian.
Tada. -- Ihope127 19:28, 23 July 2005 (UTC)
I looked at both the article and the long-winded "explanation" above for the current text (Jan 10, 2006) which states that the Indic-Arabic system of digits is always bigendian. That is totally and utter hogwash, as Tada above eminently illustrates. Embedded in a right-to-left stream, Indic-Arabic digits are clearly littleendian. If one chooses to interrupt the order and read the digits left-to-right, then of course it's bigendian -- but that's not a property of the digits! The fact that Hebrew (the example used) may deal with numbers in a bigendian fashion has nothing to do with it. Contrapositively, Danish is an example of a language written with a left-to-right script (Latin) which deals with numbers in a littleendian fashion -- the number 82 is read as to og firs (two-and-eighty) -- a littleendian treatment, but according to the article's argument, that would imply Indic-Arabic letters are always littleendian!
I do intend to change this, obviously. The argument is ridiculous.
-- User:HpaScalar 10 Jan 2006
103
|
102
|
101
|
100
|
||
...
|
1D
|
2C
|
3B
|
4A
|
...
|
A spelling question: is "Big-endian" spelled with or without the hypen? The article has mostly with, but a few without, for example, in the "Portability Issues" section, we have:
"... if the data are stored using big endian integers ..."
and in the "Discussion, background, etymology" section:
" ... The spoken numeral system in English is big endian (with minor exceptions ..."
These are the only two such examples I find, the rest are more like:
"... In a consistently big-endian architecture ..."
I suspect the hyphen should be required and the first two examples should be corrected. Yes?
Currently the example code is not legal C, or even C++. (Neither has a "boolean" type for one thing)
The lead-in to the example was recently changed to assert that the code assumes that char is 1 byte. The code does not have to assume this; char is defined to be 1 byte. (A byte is not necessarily defined to be an octet, but the code doesn't make any assumptions about that.) You could read the ANSI and ISO C standards (89/90 and 99), the C++ standards, and the manuals for every common pre-standard compiler if you wanted. Or just see http://www.parashift.com/c++-faq-lite/intrinsic-types.html (which is C++, granted, but the same is true in C).
Note that int > char is still an assumption. For example, an embedded system or DSP that couldn't access anything smaller than a word efficiently (or at all) might define char, short, and int to all be one machine word, 16 bits. The code would not work on such a compiler. Falcotron 05:41, 27 June 2006 (UTC)
The most recent change to the example improves things in two ways:
But:
True, the code could still be wrong if, e.g., sizeof(intmax_t) > sizeof(long) == sizeof(char). But this could not have any effect on portable C89 code, and it's not detectable with portable C89 code. If you're using C99 (or a compiler with similar extensions), just use intmax_t (or the largest type you intend to use) in place of long in the code, and it'll work fine.
Also, I thought it might be a good idea to point out that middle-endian systems will be incorrectly detected as little-endian, rather than just saying that they won't be detected.
So, I reverted the code and fixed the preceding discussion. I also added a short discussion above about systems with all types the same size further up. And I fixed some minor typos and grammatical errors.
I'm not sure mention of any of this extra complexity with 32-bit-byte systems and so on needs to be in the article at all--but I'm guessing that if it's not there, someone will add something overly complicated again, so I tried to come up with something correct that fits in a single parenthesized sentence. -- Falcotron 04:22, 25 July 2006 (UTC)
int bigendian() { long i = 1; const char *p = (const char *) &i; return p[0] != 1; /* Lowest address doesn't contain least significant byte */ }
I added a one-line mention of the Berkely sockets conversion functions (htonl and friends) since Wikipedia had no hits for them. I'm adding a redirect from those functions to this article: is that appropriate, or should I write a new "endianness conversion function" stub or something? -- Victor Lighthill 20:10, 17 November 2005 (UTC)
As a reader, I'd prefer to have all topics around Endianness located in one place. Conversion functions are furthermore highly relevant to allow Endian heterogeneous systems to communicate. I ended up with following comversion functions (Z/Z' is element size, ZS/ZS' is atomic element unit, l is little-endian, b is big-endian). Is it aligned with your study? Bblanc 12:21, 29 August 2006 (UTC)