




some tricky questions
1) void foo(char *s,char *t) { while(*s++=*t++); } which C function is equivalent to foo ? 2) #define ROUND(x,n) ((x+n1)&(~(n1))) what is hte value of ROUND(223,64) ? DESCRIBE IT HOW IT IS SO? 3) void foo(int x) { int i=0; while(x) { x=x&(x1); i++; } printf("%d",i); } what is the o/p of this function & why it is so ? what function does this '&' does ? 4) union{ int i; char c[sizeof(int)]; }x; x.i=1; if(x.c[0]==1) printf("the m/c is _______________ endian"); else printf("the m/c is _______________ endian"); fill in the blanks with tthe correct option: a) little,big b)big,big c) big,little d)little,little 5) int fun2(char *a,char *b) { for(; *a==*b;a++,b++) if(*a=='\0') return 0; return *a*b; } char a[10]="date",b[10]="data"; what is the value of fun2(a,b)?
birensubu @gmail.com wrote: > 1) void foo(char *s,char *t) > { > while(*s++=*t++); > } > which C function is equivalent to foo ?
FYI, we don't do homework.  Tor <torust [at] online [dot] no>
<birensubu@gmail.com> ha scritto nel messaggio news:1180772304.807456.242510@n15g2000prd.googlegroups.com... > 1) void foo(char *s,char *t) > { > while(*s++=*t++); > } > which C function is equivalent to foo ?
None. strcpy returns a char* equal to its first argument. Also, the second argument of strcpy is a const char*. > 2) #define ROUND(x,n) > ((x+n1)&(~(n1))) > what is hte value of ROUND(223,64) ? > DESCRIBE IT HOW IT IS SO?
It is the value of ((223+641)&(~(641))), of course. > 3) void foo(int x) > { > int i=0; > while(x) > { > x=x&(x1); > i++; > } > printf("%d",i); > } > what is the o/p of this function & why it is so ? > what function does this '&' does ?
If x is INT_MIN, it is allowed to make demons fly out of your nose. BTW, what is an o/p? And the '&' does no "function", at least in the C sense. > 4) union{ > int i; > char c[sizeof(int)]; > }x; > x.i=1; > if(x.c[0]==1) > printf("the m/c is _______________ endian"); > else > printf("the m/c is _______________ endian"); > fill in the blanks with tthe correct option: > a) little,big b)big,big > c) big,little d)little,little
Nope. It could be middle endian. And if I'm not wrong, the standard specifies nothing about the bit order. On a conforming implementation, it could be sizeof (int) == 2 && CHAR_BIT ==8, and the first byte of i could contain the first, third, fifth, seventh, ninth, eleventh, thirteenth, and fifteenth bit in that order, and the second byte could contain the sixteenth, fourteenth, ..., second bit in that order. > 5) int fun2(char *a,char *b) > { > for(; *a==*b;a++,b++) > if(*a=='\0') > return 0; > return *a*b; > } > char a[10]="date",b[10]="data"; > what is the value of fun2(a,b)?
It is 'e'  'a', which nothing requires to be four. It could be anything from CHAR_MIN  CHAR_MAX to 1 included, and it could be anything from 1 to CHAR_MAX  CHAR_MIN included. Not all the world uses ASCII.
On Jun 2, 12:28 pm, "Army1987" <please.@for.it> wrote: > <birensubu @gmail.com> ha scritto nel messaggio news:1180772304.807456.242510@n15g2000prd.googlegroups.com... > [...] > > 2) #define ROUND(x,n) > > ((x+n1)&(~(n1))) > > what is hte value of ROUND(223,64) ? > > DESCRIBE IT HOW IT IS SO? > It is the value of ((223+641)&(~(641))), of course. > [...]
The reason: "by definition". [:)]< /Per  Per Erik Strandberg home: www.pererikstrandberg.se work: www.incf.org also: www.spongswedencare.se
In article <1180772304.807456.242@n15g2000prd.googlegroups.com>, <birensubu @gmail.com> wrote: >1) void foo(char *s,char *t) > { > while(*s++=*t++); > } >which C function is equivalent to foo ?
What is homework, Alex?
birensubu @gmail.com writes: > 1) void foo(char *s,char *t) > { > while(*s++=*t++); > } > which C function is equivalent to foo ?
foo.  Keith Thompson (The_Other_Keith) k@mib.org <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> "We must do something. This is something. Therefore, we must do this."  Antony Jay and Jonathan Lynn, "Yes Minister"
On Jun 2, 6:28 am, "Army1987" <please.@for.it> wrote:
> <birensubu @gmail.com> ha scritto nel messaggio news:1180772304.807456.242510@n15g2000prd.googlegroups.com... > > 1) void foo(char *s,char *t) > > { > > while(*s++=*t++); > > } > > which C function is equivalent to foo ? > None. strcpy returns a char* equal to its first argument. Also, the > second argument of strcpy is a const char*. > > 2) #define ROUND(x,n) > > ((x+n1)&(~(n1))) > > what is hte value of ROUND(223,64) ? > > DESCRIBE IT HOW IT IS SO? > It is the value of ((223+641)&(~(641))), of course. > > 3) void foo(int x) > > { > > int i=0; > > while(x) > > { > > x=x&(x1); > > i++; > > } > > printf("%d",i); > > } > > what is the o/p of this function & why it is so ? > > what function does this '&' does ? > If x is INT_MIN, it is allowed to make demons fly out of your nose. > BTW, what is an o/p? And the '&' does no "function", at least in the C > sense. > > 4) union{ > > int i; > > char c[sizeof(int)]; > > }x; > > x.i=1; > > if(x.c[0]==1) > > printf("the m/c is _______________ endian"); > > else > > printf("the m/c is _______________ endian"); > > fill in the blanks with tthe correct option: > > a) little,big b)big,big > > c) big,little d)little,little > Nope. It could be middle endian.
Right. > And if I'm not wrong, the standard > specifies nothing about the bit order. On a conforming implementation, it > could be sizeof (int) == 2 && CHAR_BIT ==8, and > the first byte of i could contain the first, third, fifth, seventh, > ninth, eleventh, thirteenth, and fifteenth bit in that order, and > the second byte could contain the sixteenth, fourteenth, ..., second bit in > that order.
Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2. Robert Gamble
Tor Rustad <tor_rus @hotmail.com> writes: > birensubu @gmail.com wrote: >> 1) void foo(char *s,char *t) >> { >> while(*s++=*t++); >> } >> which C function is equivalent to foo ? > FYI, we don't do homework.
Who is "we"? Because someone else did.
On Sun, 03 Jun 2007 00:12:06 +0200, in comp.lang.c , Richard
<rgr @gmail.com> wrote: >Tor Rustad <tor_rus @hotmail.com> writes: >> birensubu@gmail.com wrote: >>> 1) void foo(char *s,char *t) >>> { >>> while(*s++=*t++); >>> } >>> which C function is equivalent to foo ? >> FYI, we don't do homework. >Who is "we"? Because someone else did.
Did'ja read the answers? Not entirely likely to pass the homework test...  Mark McIntyre "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." Brian Kernighan
Richard wrote: > Tor Rustad <tor_rus @hotmail.com> writes: [...] >> FYI, we don't do homework. > Who is "we"? Because someone else did.
I exclude spammers, and that someone else was spamming in my view.  Tor <torust [at] online [dot] no>
"Robert Gamble" <rgambl@gmail.com> ha scritto nel messaggio news:1180821327.758043.319990@h2g2000hsg.googlegroups.com... >> And if I'm not wrong, the standard >> specifies nothing about the bit order. On a conforming implementation, it >> could be sizeof (int) == 2 && CHAR_BIT ==8, and >> the first byte of i could contain the first, third, fifth, seventh, >> ninth, eleventh, thirteenth, and fifteenth bit in that order, and >> the second byte could contain the sixteenth, fourteenth, ..., second bit >> in >> that order. > Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2.
Unless the actual standard differs from n1124.pdf, it says: If there are N value bits, each bit shall represent a different power of 2 between 1 and 2^(N?1), [...] Nowhere does it says anything about how are these ordered. Maybe on the DS9K this is decided randomly at program startup.
On Jun 3, 11:16 am, "Army1987" <please.@for.it> wrote:
> "Robert Gamble" <rgambl @gmail.com> ha scritto nel messaggio news:1180821327.758043.319990@h2g2000hsg.googlegroups.com... > >> And if I'm not wrong, the standard > >> specifies nothing about the bit order. On a conforming implementation, it > >> could be sizeof (int) == 2 && CHAR_BIT ==8, and > >> the first byte of i could contain the first, third, fifth, seventh, > >> ninth, eleventh, thirteenth, and fifteenth bit in that order, and > >> the second byte could contain the sixteenth, fourteenth, ..., second bit > >> in > >> that order. > > Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2. > Unless the actual standard differs from n1124.pdf, it says: > If there are N value bits, each bit shall represent a different > power of 2 between 1 and 2^(N?1), [...] > Nowhere does it says anything about how are these ordered.
Let me know when you make it through the second half of that sentence. Robert Gamble
On Sun, 03 Jun 2007 21:55:10 0000, in comp.lang.c , Robert Gamble
<rgambl @gmail.com> wrote: >On Jun 3, 11:16 am, "Army1987" <please. @for.it> wrote: >> "Robert Gamble" <rgambl @gmail.com> ha scritto nel messaggio news:1180821327.758043.319990@h2g2000hsg.googlegroups.com... >> >> And if I'm not wrong, the standard >> >> specifies nothing about the bit order. On a conforming implementation, it >> >> could be sizeof (int) == 2 && CHAR_BIT ==8, and >> >> the first byte of i could contain the first, third, fifth, seventh, >> >> ninth, eleventh, thirteenth, and fifteenth bit in that order, and >> >> the second byte could contain the sixteenth, fourteenth, ..., second bit >> >> in >> >> that order. >> > Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2. >> Unless the actual standard differs from n1124.pdf, it says: >> If there are N value bits, each bit shall represent a different >> power of 2 between 1 and 2^(N?1), [...] >> Nowhere does it says anything about how are these ordered. >Let me know when you make it through the second half of that sentence.
The second half of the sentence doesn't say ", with the powers of two being ordered sequentially throughout each octet".  Mark McIntyre "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." Brian Kernighan
On Jun 3, 6:04 pm, Mark McIntyre <markmcint@spamcop.net> wrote:
> On Sun, 03 Jun 2007 21:55:10 0000, in comp.lang.c , Robert Gamble > <rgambl@gmail.com> wrote: > >On Jun 3, 11:16 am, "Army1987" <please.@for.it> wrote: > >> "Robert Gamble" <rgambl@gmail.com> ha scritto nel messaggionews:1180821327.758043.319990@h2g2000hsg.googlegroups.com... > >> >> And if I'm not wrong, the standard > >> >> specifies nothing about the bit order. On a conforming implementation, it > >> >> could be sizeof (int) == 2 && CHAR_BIT ==8, and > >> >> the first byte of i could contain the first, third, fifth, seventh, > >> >> ninth, eleventh, thirteenth, and fifteenth bit in that order, and > >> >> the second byte could contain the sixteenth, fourteenth, ..., second bit > >> >> in > >> >> that order. > >> > Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2. > >> Unless the actual standard differs from n1124.pdf, it says: > >> If there are N value bits, each bit shall represent a different > >> power of 2 between 1 and 2^(N?1), [...] > >> Nowhere does it says anything about how are these ordered. > >Let me know when you make it through the second half of that sentence. > The second half of the sentence doesn't say ", with the powers of two > being ordered sequentially throughout each octet".
The full sentence says: "If there are N value bits, each bit shall represent a different power of 2 between 1 and 2N 1, so that objects of that type shall be capable of representing values from 0 to 2N 1 using a pure binary representation; this shall be ^^^^^ ^ ^^^^ ^^^^^^ ^^^^^^^^^^^^^^ known as the value representation." Robert Gammble
On Sun, 03 Jun 2007 22:22:49 0000, in comp.lang.c , Robert Gamble
<rgambl @gmail.com> wrote: >On Jun 3, 6:04 pm, Mark McIntyre <markmcint @spamcop.net> wrote: >> On Sun, 03 Jun 2007 21:55:10 0000, in comp.lang.c , Robert Gamble >> <rgambl@gmail.com> wrote: >> >On Jun 3, 11:16 am, "Army1987" <please.@for.it> wrote: >> >> "Robert Gamble" <rgambl@gmail.com> ha scritto nel messaggionews:1180821327.758043.319990@h2g2000hsg.googlegroups.com... >> >> >> And if I'm not wrong, the standard >> >> >> specifies nothing about the bit order. On a conforming implementation, it >> >> >> could be sizeof (int) == 2 && CHAR_BIT ==8, and >> >> >> the first byte of i could contain the first, third, fifth, seventh, >> >> >> ninth, eleventh, thirteenth, and fifteenth bit in that order, and >> >> >> the second byte could contain the sixteenth, fourteenth, ..., second bit >> >> >> in >> >> >> that order. >> >> > Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2. >> >> Unless the actual standard differs from n1124.pdf, it says: >> >> If there are N value bits, each bit shall represent a different >> >> power of 2 between 1 and 2^(N?1), [...] >> >> Nowhere does it says anything about how are these ordered. >> >Let me know when you make it through the second half of that sentence. >> The second half of the sentence doesn't say ", with the powers of two >> being ordered sequentially throughout each octet". >The full sentence says: >"If there are N value bits, each bit shall represent a different >power of 2 between 1 and 2N 1, so that objects of that type shall be >capable of >representing values from 0 to 2N 1 using a pure binary >representation; this shall be > ^^^^^ ^ ^^^^ ^^^^^^ >^^^^^^^^^^^^^^ >known as the value representation."
Assuming you underlined the "pure binary representation", it +still+ doesn't say the bits have to be in ascending or descending order. Indeed I suspect we all know some implementations where this isn't the case.  Mark McIntyre "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." Brian Kernighan
"Army1987" <please. @for.it> writes: > "Robert Gamble" <rgambl @gmail.com> ha scritto nel messaggio > news:1180821327.758043.319990@h2g2000hsg.googlegroups.com... >>> And if I'm not wrong, the standard >>> specifies nothing about the bit order. On a conforming implementation, it >>> could be sizeof (int) == 2 && CHAR_BIT ==8, and >>> the first byte of i could contain the first, third, fifth, seventh, >>> ninth, eleventh, thirteenth, and fifteenth bit in that order, and >>> the second byte could contain the sixteenth, fourteenth, ..., second bit >>> in >>> that order. >> Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2. > Unless the actual standard differs from n1124.pdf, it says: > If there are N value bits, each bit shall represent a different > power of 2 between 1 and 2^(N?1), [...] > Nowhere does it says anything about how are these ordered. Maybe > on the DS9K this is decided randomly at program startup.
What does this "ordering" mean? It seems reasonable to *define* the ordering of bits within a integer object in terms of the values they represent.  Keith Thompson (The_Other_Keith) k@mib.org <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> "We must do something. This is something. Therefore, we must do this."  Antony Jay and Jonathan Lynn, "Yes Minister"
In article <ln7iqkwrp7.@nuthaus.mib.org>, Keith Thompson <k@mib.org> wrote: >> Unless the actual standard differs from n1124.pdf, it says: >> If there are N value bits, each bit shall represent a different >> power of 2 between 1 and 2^(N?1), [...] >> Nowhere does it says anything about how are these ordered. Maybe >> on the DS9K this is decided randomly at program startup. >What does this "ordering" mean? It seems reasonable to *define* the >ordering of bits within a integer object in terms of the values they >represent.
You can test it by examining the value after logical operations on the bits. The C standard defines these to work "as expected", at least for positive integers.  Richard  "Consideration shall be given to the need for as many as 32 characters in some alphabets"  X3.4, 1963.
Keith Thompson wrote: > "Army1987" <please.@for.it> writes: > > "Robert Gamble" <rgambl@gmail.com> ha scritto nel messaggio > > news:1180821327.758043.319990@h2g2000hsg.googlegroups.com... > >>> And if I'm not wrong, the standard > >>> specifies nothing about the bit order. On a conforming implementation, it > >>> could be sizeof (int) == 2 && CHAR_BIT ==8, and > >>> the first byte of i could contain the first, third, fifth, seventh, > >>> ninth, eleventh, thirteenth, and fifteenth bit in that order, and > >>> the second byte could contain the sixteenth, fourteenth, ..., second bit > >>> in > >>> that order. > >> Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2. > > Unless the actual standard differs from n1124.pdf, it says: > > If there are N value bits, each bit shall represent a different > > power of 2 between 1 and 2^(N?1), [...] > > Nowhere does it says anything about how are these ordered. Maybe > > on the DS9K this is decided randomly at program startup. > What does this "ordering" mean? It seems reasonable to *define* the > ordering of bits within a integer object in terms of the values they > represent.
However, if an integer type has more than one byte, there's nothing that says that the two lowest order bits must be on the same byte.  pete
On Jun 3, 6:35 pm, Mark McIntyre <markmcint@spamcop.net> wrote:
> On Sun, 03 Jun 2007 22:22:49 0000, in comp.lang.c , Robert Gamble > <rgambl@gmail.com> wrote: > >On Jun 3, 6:04 pm, Mark McIntyre <markmcint@spamcop.net> wrote: > >> On Sun, 03 Jun 2007 21:55:10 0000, in comp.lang.c , Robert Gamble > >> <rgambl@gmail.com> wrote: > >> >On Jun 3, 11:16 am, "Army1987" <please.@for.it> wrote: > >> >> "Robert Gamble" <rgambl@gmail.com> ha scritto nel messaggionews:1180821327.758043.319990@h2g2000hsg.googlegroups.com... > >> >> >> And if I'm not wrong, the standard > >> >> >> specifies nothing about the bit order. On a conforming implementation, it > >> >> >> could be sizeof (int) == 2 && CHAR_BIT ==8, and > >> >> >> the first byte of i could contain the first, third, fifth, seventh, > >> >> >> ninth, eleventh, thirteenth, and fifteenth bit in that order, and > >> >> >> the second byte could contain the sixteenth, fourteenth, ..., second bit > >> >> >> in > >> >> >> that order. > >> >> > Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2. > >> >> Unless the actual standard differs from n1124.pdf, it says: > >> >> If there are N value bits, each bit shall represent a different > >> >> power of 2 between 1 and 2^(N?1), [...] > >> >> Nowhere does it says anything about how are these ordered. > >> >Let me know when you make it through the second half of that sentence. > >> The second half of the sentence doesn't say ", with the powers of two > >> being ordered sequentially throughout each octet". > >The full sentence says: > >"If there are N value bits, each bit shall represent a different > >power of 2 between 1 and 2N 1, so that objects of that type shall be > >capable of > >representing values from 0 to 2N 1 using a pure binary > >representation; this shall be > > ^^^^^ ^ ^^^^ ^^^^^^ > >^^^^^^^^^^^^^^ > >known as the value representation." > Assuming you underlined the "pure binary representation", it +still+ > doesn't say the bits have to be in ascending or descending order.
Here is the definition of "pure binary representation" provided by the Standard as a footnote in 6.2.6.1: "A positional representation for integers that uses the binary digits 0 and 1, in which the values represented by successive bits are additive, begin with 1, and are multiplied by successive integral powers of 2, except perhaps the bit with the highest position." Note the "successive" parts. The example presented doesn't fit that description. > Indeed I suspect we all know some implementations where this isn't the > case.
Then I suspect you would be able to provide at least one such implementation? How do shifts work on that implementation? Robert Gamble
Robert Gamble <rgambl @gmail.com> writes: > On Jun 3, 6:35 pm, Mark McIntyre <markmcint @spamcop.net> wrote: >> On Sun, 03 Jun 2007 22:22:49 0000, in comp.lang.c , Robert Gamble >> <rgambl @gmail.com> wrote: >> >On Jun 3, 6:04 pm, Mark McIntyre <markmcint @spamcop.net> wrote: >> >> On Sun, 03 Jun 2007 21:55:10 0000, in comp.lang.c , Robert Gamble >> >> <rgambl@gmail.com> wrote: >> >> >On Jun 3, 11:16 am, "Army1987" <please.@for.it> wrote: >> >> >> "Robert Gamble" <rgambl@gmail.com> ha scritto nel messaggionews:1180821327.758043.319990@h2g2000hsg.googlegroups.com... >> >> >> >> And if I'm not wrong, the standard >> >> >> >> specifies nothing about the bit order. On a conforming implementation, it >> >> >> >> could be sizeof (int) == 2 && CHAR_BIT ==8, and >> >> >> >> the first byte of i could contain the first, third, fifth, seventh, >> >> >> >> ninth, eleventh, thirteenth, and fifteenth bit in that order, and >> >> >> >> the second byte could contain the sixteenth, fourteenth, ..., second bit >> >> >> >> in >> >> >> >> that order. >> >> >> > Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2. >> >> >> Unless the actual standard differs from n1124.pdf, it says: >> >> >> If there are N value bits, each bit shall represent a different >> >> >> power of 2 between 1 and 2^(N?1), [...] >> >> >> Nowhere does it says anything about how are these ordered. >> >> >Let me know when you make it through the second half of that sentence. >> >> The second half of the sentence doesn't say ", with the powers of two >> >> being ordered sequentially throughout each octet". >> >The full sentence says: >> >"If there are N value bits, each bit shall represent a different >> >power of 2 between 1 and 2N 1, so that objects of that type shall be >> >capable of >> >representing values from 0 to 2N 1 using a pure binary >> >representation; this shall be >> > ^^^^^ ^ ^^^^ ^^^^^^ >> >^^^^^^^^^^^^^^ >> >known as the value representation." >> Assuming you underlined the "pure binary representation", it +still+ >> doesn't say the bits have to be in ascending or descending order. > Here is the definition of "pure binary representation" provided by the > Standard as a footnote in 6.2.6.1: > "A positional representation for integers that uses the binary digits > 0 and 1, in which the values > represented by successive bits are additive, begin with 1, and are > multiplied by successive integral > powers of 2, except perhaps the bit with the highest position." > Note the "successive" parts. The example presented doesn't fit that > description. >> Indeed I suspect we all know some implementations where this isn't the >> case. > Then I suspect you would be able to provide at least one such > implementation?
I know a machine that used the following byte order for longs: 2143  the less significant half word had a lower address than the more significant half word, but within them the more significant byte preceded the less significant one. I can't claim that this machine had a conforming C implementation because it was a long time ago. It had a C compiler but it predated C90. Do you interpret the standard to say that it could not have a conforming implementation? > How do shifts work on that implementation?
Shifts worked by doing what was needed to move the bits around in the right order (although my memory is hazy about this). Shifts are defined by the arithmetic value of the result, so a conforming implementation has no choice but to generate code that does whatever is required. Because this particular machine was microcoded, I seem to remember that the team had designed a pair of shift instructions that did the job. But even if there were only half word shifts available, the compiler would simply have had to generate two of them (along with a test and an OR). I would be surprised if the wording you quote was intended to prevent such a machine from having a conforming C implementation. I suspect that the wording is intended to reinforce the idea that the value bits look consecutive as far as C programs are concerned. In other words, that shifts and bitwise logical operations all work together as defined later on.  Ben.
On Mon, 04 Jun 2007 02:42:39 0000, in comp.lang.c , Robert Gamble <rgambl @gmail.com> wrote: >On Jun 3, 6:35 pm, Mark McIntyre <markmcint @spamcop.net> wrote: >> On Sun, 03 Jun 2007 22:22:49 0000, in comp.lang.c , Robert Gamble >> Assuming you underlined the "pure binary representation", it +still+ >> doesn't say the bits have to be in ascending or descending order. >Here is the definition of "pure binary representation" provided by the >Standard as a footnote in 6.2.6.1:
While i don't dispute the text, I should point out that footnotes are not normative. >Then I suspect you would be able to provide at least one such >implementation?
x86. >How do shifts work on that implementation?
Same as anywhere else. The standard requires them to do what you expect, but this need not map onto the actual order of bits in memory.  Mark McIntyre "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." Brian Kernighan
On Jun 4, 8:57 am, Mark McIntyre <markmcint@spamcop.net> wrote:
> On Mon, 04 Jun 2007 02:42:39 0000, in comp.lang.c , Robert Gamble > <rgambl@gmail.com> wrote: > >On Jun 3, 6:35 pm, Mark McIntyre <markmcint@spamcop.net> wrote: > >> On Sun, 03 Jun 2007 22:22:49 0000, in comp.lang.c , Robert Gamble > >> Assuming you underlined the "pure binary representation", it +still+ > >> doesn't say the bits have to be in ascending or descending order. > >Here is the definition of "pure binary representation" provided by the > >Standard as a footnote in 6.2.6.1: > While i don't dispute the text, I should point out that footnotes are > not normative. > >Then I suspect you would be able to provide at least one such > >implementation? > x86.
Are you referring to BCD? If so, such a representation is not compatible with the Standard, if not you should be more specific. > >How do shifts work on that implementation? > Same as anywhere else. The standard requires them to do what you > expect, but this need not map onto the actual order of bits in memory.
Well obviously the implementation can store the information however it pleases as long as it appears "asif" it conformed to the Standard and a s.c. program must not be able to tell the difference. In the example presented by Army1987 the assumption was that the program was able to tell the difference. Robert Gamble
On Mon, 04 Jun 2007 13:11:47 0000, in comp.lang.c , Robert Gamble <rgambl @gmail.com> wrote: >Are you referring to BCD? If so, such a representation is not >compatible with the Standard, if not you should be more specific. I was thinking of endianness. If you copy a long into an array of unsigned chars, the bits are not in the 'right' order. >> >How do shifts work on that implementation? >> Same as anywhere else. The standard requires them to do what you >> expect, but this need not map onto the actual order of bits in memory. >Well obviously the implementation can store the information however it >pleases as long as it appears "asif"
Agreed. This was kinda the point.  Mark McIntyre "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." Brian Kernighan
Mark McIntyre <markmcint @spamcop.net> writes: > On Mon, 04 Jun 2007 02:42:39 0000, in comp.lang.c , Robert Gamble > <rgambl @gmail.com> wrote: [...] >>How do shifts work on that implementation? > Same as anywhere else. The standard requires them to do what you > expect, but this need not map onto the actual order of bits in memory.
I'm not convinced that the "actual order of bits in memory" is even meaningful. On systems that don't address bits directly, there may be no such concept, except perhaps one defined by convention for documentation purposes.  Keith Thompson (The_Other_Keith) k@mib.org <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> "We must do something. This is something. Therefore, we must do this."  Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote On 06/04/07 16:03,:
> Mark McIntyre <markmcint @spamcop.net> writes: >>On Mon, 04 Jun 2007 02:42:39 0000, in comp.lang.c , Robert Gamble >><rgambl@gmail.com> wrote: > [...] >>>How do shifts work on that implementation? >>Same as anywhere else. The standard requires them to do what you >>expect, but this need not map onto the actual order of bits in memory. > I'm not convinced that the "actual order of bits in memory" is even > meaningful. On systems that don't address bits directly, there may be > no such concept, except perhaps one defined by convention for > documentation purposes.
Agreed. Here's a thought experiment I've suggested before; perhaps it's a good time to drag it out again. In the pursuit of ever greater density and ever lower power consumption, somebody builds a basefour computer using fourstate instead of twostate devices. Integers on this machine are represented in quartal instead of in binary, with fourquit bytes, eightquit shorts, and so on. However, the manufacturer decided that introducing the world's first quartal computer would scare off too many buyers; they'd shake their heads and say "It's too weird for me" and buy the binary competition. So even though the machine uses fourstate devices the documentation is careful to conceal this fact: it says (with its fingers crossed) that the machine operates in binary and (with a straight face) describes the order of individual bits within various integer sizes. Since the 1's bit and the 2's bit are in fact just different aspects of the value of one single quit this description is largely fantasy, but it's not the first time a computer manufacturer has lied to you, is it? Surprisingly enough, I happen to know (by means I am not at liberty to divulge) that the machine you are using right at this very moment is a quartal wonder masquerading as a plain vanilla binary machine. Ask the manufacturer and you'll get a flatout denial, but I Happen To Know. On your machine, the 1's bit and the 2's bit are not neighbors, neither is to the left or right of the other  they are in the exact same place. With this longwinded setup out of the way, here comes the experiment itself: Can you devise a C program to test whether I'm right or wrong about the nature of your machine? If you cannot, I submit that if C cannot even tell whether individual bits exist as separable entities, it cannot begin to tell how these unisolatable entities are arranged.  Eric.Sos@sun.com





