473,221 Members | 1,786 Online

# 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+n-1)&(~(n-1)))
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&(x-1);
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)?

Jun 2 '07 #1
28 13542
bi**********@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>
Jun 2 '07 #2

<bi**********@gmail.comha scritto nel messaggio
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+n-1)&(~(n-1)))
what is hte value of ROUND(223,64) ?
DESCRIBE IT HOW IT IS SO?
It is the value of ((223+64-1)&(~(64-1))), of course.
3) void foo(int x)
{
int i=0;
while(x)
{
x=x&(x-1);
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.
Jun 2 '07 #3
On Jun 2, 12:28 pm, "Army1987" <please....@for.itwrote:

[...]
2) #define ROUND(x,n)
((x+n-1)&(~(n-1)))
what is hte value of ROUND(223,64) ?
DESCRIBE IT HOW IT IS SO?

It is the value of ((223+64-1)&(~(64-1))), of course.
[...]
The reason: "by definition".
[:)]-|--<

/Per

--

Per Erik Strandberg
home: www.pererikstrandberg.se
work: www.incf.org
also: www.spongswedencare.se

Jun 2 '07 #4
<bi**********@gmail.comwrote:
>1) void foo(char *s,char *t)
{
while(*s++=*t++);
}

which C function is equivalent to foo ?
What is homework, Alex?

Jun 2 '07 #5
bi**********@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) ks***@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"
Jun 2 '07 #6
On Jun 2, 6:28 am, "Army1987" <please....@for.itwrote:
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+n-1)&(~(n-1)))
what is hte value of ROUND(223,64) ?
DESCRIBE IT HOW IT IS SO?

It is the value of ((223+64-1)&(~(64-1))), of course.
3) void foo(int x)
{
int i=0;
while(x)
{
x=x&(x-1);
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.

Robert Gamble

Jun 2 '07 #7
bi**********@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.
Jun 2 '07 #8
On Sun, 03 Jun 2007 00:12:06 +0200, in comp.lang.c , Richard
<rg****@gmail.comwrote:
>bi**********@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.
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
Jun 2 '07 #9
Richard wrote:
[...]
>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>
Jun 3 '07 #10

"Robert Gamble" <rg*******@gmail.comha scritto nel messaggio
>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.

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.
Jun 3 '07 #11
On Jun 3, 11:16 am, "Army1987" <please....@for.itwrote:
"Robert Gamble" <rgambl...@gmail.comha scritto nel messaggionews:11**********************@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.

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

Jun 3 '07 #12
On Sun, 03 Jun 2007 21:55:10 -0000, in comp.lang.c , Robert Gamble
<rg*******@gmail.comwrote:
>On Jun 3, 11:16 am, "Army1987" <please....@for.itwrote:
>"Robert Gamble" <rgambl...@gmail.comha scritto nel messaggionews:11**********************@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.

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
Jun 3 '07 #13
On Jun 3, 6:04 pm, Mark McIntyre <markmcint...@spamcop.netwrote:
On Sun, 03 Jun 2007 21:55:10 -0000, in comp.lang.c , Robert Gamble

<rgambl...@gmail.comwrote:
On Jun 3, 11:16 am, "Army1987" <please....@for.itwrote:
"Robert Gamble" <rgambl...@gmail.comha scritto nel messaggionews:11**********************@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.
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

Jun 3 '07 #14
On Sun, 03 Jun 2007 22:22:49 -0000, in comp.lang.c , Robert Gamble
<rg*******@gmail.comwrote:
>On Jun 3, 6:04 pm, Mark McIntyre <markmcint...@spamcop.netwrote:
>On Sun, 03 Jun 2007 21:55:10 -0000, in comp.lang.c , Robert Gamble

<rgambl...@gmail.comwrote:
>On Jun 3, 11:16 am, "Army1987" <please....@for.itwrote:
"Robert Gamble" <rgambl...@gmail.comha scritto nel messaggionews:11**********************@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.
>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
Jun 3 '07 #15
"Army1987" <pl********@for.itwrites:
"Robert Gamble" <rg*******@gmail.comha scritto nel messaggio
>>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.

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) ks***@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"
Jun 3 '07 #16
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>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.
Jun 4 '07 #17
Keith Thompson wrote:
>
"Army1987" <pl********@for.itwrites:
"Robert Gamble" <rg*******@gmail.comha scritto nel messaggio
>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.

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
Jun 4 '07 #18
On Jun 3, 6:35 pm, Mark McIntyre <markmcint...@spamcop.netwrote:
On Sun, 03 Jun 2007 22:22:49 -0000, in comp.lang.c , Robert Gamble

<rgambl...@gmail.comwrote:
On Jun 3, 6:04 pm, Mark McIntyre <markmcint...@spamcop.netwrote:
On Sun, 03 Jun 2007 21:55:10 -0000, in comp.lang.c , Robert Gamble
<rgambl...@gmail.comwrote:
On Jun 3, 11:16 am, "Army1987" <please....@for.itwrote:
"Robert Gamble" <rgambl...@gmail.comha scritto nel messaggionews:11**********************@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.
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

Jun 4 '07 #19
Robert Gamble <rg*******@gmail.comwrites:
On Jun 3, 6:35 pm, Mark McIntyre <markmcint...@spamcop.netwrote:
>On Sun, 03 Jun 2007 22:22:49 -0000, in comp.lang.c , Robert Gamble
<rgambl...@gmail.comwrote:
>On Jun 3, 6:04 pm, Mark McIntyre <markmcint...@spamcop.netwrote:
On Sun, 03 Jun 2007 21:55:10 -0000, in comp.lang.c , Robert Gamble
><rgambl...@gmail.comwrote:
On Jun 3, 11:16 am, "Army1987" <please....@for.itwrote:
"Robert Gamble" <rgambl...@gmail.comha scritto nel messaggionews:11**********************@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.
>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 pre-dated 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
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 micro-coded, 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 bit-wise logical operations all work together as
defined later on.

--
Ben.
Jun 4 '07 #20
On Mon, 04 Jun 2007 02:42:39 -0000, in comp.lang.c , Robert Gamble
<rg*******@gmail.comwrote:
>On Jun 3, 6:35 pm, Mark McIntyre <markmcint...@spamcop.netwrote:
>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
Jun 4 '07 #21
On Jun 4, 8:57 am, Mark McIntyre <markmcint...@spamcop.netwrote:
On Mon, 04 Jun 2007 02:42:39 -0000, in comp.lang.c , Robert Gamble

<rgambl...@gmail.comwrote:
On Jun 3, 6:35 pm, Mark McIntyre <markmcint...@spamcop.netwrote:
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 "as-if" 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

Jun 4 '07 #22
On Mon, 04 Jun 2007 13:11:47 -0000, in comp.lang.c , Robert Gamble
<rg*******@gmail.comwrote:
>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 "as-if"
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
Jun 4 '07 #23
Mark McIntyre <ma**********@spamcop.netwrites:
On Mon, 04 Jun 2007 02:42:39 -0000, in comp.lang.c , Robert Gamble
<rg*******@gmail.comwrote:
[...]
>>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) ks***@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"
Jun 4 '07 #24
Keith Thompson wrote On 06/04/07 16:03,:
Mark McIntyre <ma**********@spamcop.netwrites:
>>On Mon, 04 Jun 2007 02:42:39 -0000, in comp.lang.c , Robert Gamble
<rg*******@gmail.comwrote:

[...]
>>>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 base-four computer
using four-state instead of two-state devices. Integers
on this machine are represented in quartal instead of in
binary, with four-quit bytes, eight-quit shorts, and so on.

However, the manufacturer decided that introducing the
world's first quartal computer would scare off too many
for me" and buy the binary competition. So even though the
machine uses four-state 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 flat-out 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 long-winded setup out of the way, here comes
the experiment itself: Can you devise a C program to test
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 un-isolatable entities are arranged.

--
Er*********@sun.com
Jun 4 '07 #25
On Jun 2, 10:28 pm, "Army1987" <please....@for.itwrote:
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.
Why do you pick those particular ranges?
Suppose CHAR_MIN is -128, 'e' is -100 and 'a' is 50.
(Then the behaviour is undefined).
Not all the world uses ASCII.
Do you know of any character set that has ever been
used in a conforming implementation where 'e' - 'a'
was not 4?

Jun 4 '07 #26
Old Wolf <ol*****@inspire.net.nzwrote:
>Do you know of any character set that has ever been
used in a conforming implementation where 'e' - 'a'
was not 4?
Never seen one myself, but I seem to recall reading of some
systems that used a Gray Code alphabet -- but I don't have any
clue as to whether a conforming implementation was every built
for those (possibly mythical) machines.
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell
Jun 5 '07 #27
In article <1180990441.814284@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:
>Keith Thompson wrote On 06/04/07 16:03,:
>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 base-four computer
using four-state instead of two-state devices. Integers
on this machine are represented in quartal instead of in
binary, with four-quit bytes, eight-quit shorts, and so on.

However, the manufacturer decided that introducing the
world's first quartal computer would scare off too many
for me" and buy the binary competition. So even though the
machine uses four-state 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 flat-out 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 long-winded setup out of the way, here comes
the experiment itself: Can you devise a C program to test
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 un-isolatable entities are arranged.
Run this program, and while it's running expose the system to a convenient
source of cosmic rays.
Wait for the cosmic rays to introduce memory errors, observe the pattern
of the errors, and look for pairs of bits whose errors are correlated.
If the cosmic ray affects the state of a quit, two bits will be affected,
and you would expect to see both of those flip often enough to notice
a pattern.

--------
#include <stdlib.h>
#include <stdio.h>
#include <time.h>

int main(void)
{
unsigned seed=(unsigned)time(0);
int *big_array=malloc(128 * sizeof *big_array);
size_t big_arr_size=128;
size_t i,j;
void *t;

if(!big_array)
{
puts("Can't allocate memory, giving up");
return EXIT_FAILURE;
}

while(t=realloc(big_array,size*2*sizeof *big_array)
{
size*=2;
big_array=t;
}

srand(seed);
for(i=0;i<size;i++)
{
big_array[i]=rand();
}

while(1)
{
srand(seed);
for(i=0;i<size;i++)
{
int expected=rand();
if(big_array[i]!=expected)
{
printf("%lu: Expected %d, got %d\n",i,expected,big_array[i]);
printf("Bytes:\nExpected: ");
for(j=0;j<sizeof expected;j++)
printf(" %x",(unsigned)(((unsigned char *)&expected)[j]));
printf("\nGot: ");
for(j=0;j<sizeof big_array[i];j++)
printf(" %x",(unsigned)(((unsigned char *)&(big_array[i]))[j]));
puts("");
big_array[i]=expected;
}
}
}
/*not reached*/
}
--------

(I should add, for those who haven't realized it by this point, that I'm
not entirely serious here; this makes the assumption that the execution
environment WILL FAIL to conform to the C standard and attempts to
gain information from that failure, and will be broken by hardware or
software that attempts to detect and correct for, or reliably trap on,
these failures.)
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
I sense some Perl coming on. --Mike Andrews and Steve VanDevender
Be sure to [...] have someone nearby if a particularly in the scary
severe attack requires restraint or sedation. devil monastery
Jun 5 '07 #28
>On Jun 2, 10:28 pm, "Army1987" <please....@for.itwrote:
>'e' - 'a' ... could be
anything from CHAR_MIN - CHAR_MAX to -1 included, and it could be
anything from 1 to CHAR_MAX - CHAR_MIN included.
Old Wolf <ol*****@inspire.net.nzwrote:
>Why do you pick those particular ranges?
Suppose CHAR_MIN is -128, 'e' is -100 and 'a' is 50. ...
This is not allowed. CHAR_MIN can be negative but 'e' must be
positive, as must all the characters that are part of the "C
alphabet". (More specifically, any "member of the required source
character set" must be result in a positive value when stored in
a plain "char". Some reasonable assumptions like INT_MAX >= CHAR_MAX
then give you "all character constants for required-source-set
characters are positive". Note that while '\0' is a character
constant, the NUL it makes it is not a member of the "required
source set".)

Given that 'e' and 'a' are both positive, and hence both in
[1..CHAR_MAX], it seems that the subtraction must produce a value
between CHAR_MAX - 1 (at the high end, where 'e' is CHAR_MAX and
'a' is 1) and 1 - CHAR_MAX (at the low end, where 'e' is 1 and 'a'
is CHAR_MAX). Of course the latter would be negative.
>Do you know of any character set that has ever been
used in a conforming implementation where 'e' - 'a'
was not 4?
(I do not, myself. But I only know about ASCII, EBCDIC, Fieldata,
and Unicode. Fieldata cannot be used for C as it lacks too many
required symbols. Interestingly, on 8-bit EBCDIC machines, plain
"char" is necessarily unsigned, since '9' is 0xf9.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603