some tricky questions

Discussion in 'C Programming' started by birensubudhi@gmail.com, Jun 2, 2007.

  1. Guest

    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, 2007
    #1
    1. Advertising

  2. Tor Rustad Guest

    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>
    Tor Rustad, Jun 2, 2007
    #2
    1. Advertising

  3. Army1987 Guest

    <> ha scritto nel messaggio
    news:...
    > 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.
    Army1987, Jun 2, 2007
    #3
  4. per9000 Guest

    On Jun 2, 12:28 pm, "Army1987" <> wrote:
    > <> ha scritto nel messaggionews:...
    >
    > [...]
    >
    > > 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
    per9000, Jun 2, 2007
    #4
  5. In article <>,
    <> wrote:
    >1) void foo(char *s,char *t)
    > {
    > while(*s++=*t++);
    >
    >
    > }
    >
    >which C function is equivalent to foo ?


    What is homework, Alex?
    Kenny McCormack, Jun 2, 2007
    #5
  6. writes:
    > 1) void foo(char *s,char *t)
    > {
    > while(*s++=*t++);
    >
    >
    > }
    >
    > which C function is equivalent to foo ?


    foo.

    --
    Keith Thompson (The_Other_Keith) <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, Jun 2, 2007
    #6
  7. On Jun 2, 6:28 am, "Army1987" <> wrote:
    > <> ha scritto nel messaggionews:...
    >
    > > 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.


    Thankfully you are wrong about this, see 9899:1999 section 6.2.6.2.

    Robert Gamble
    Robert Gamble, Jun 2, 2007
    #7
  8. Richard Guest

    Tor Rustad <> writes:

    > 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.
    Richard, Jun 2, 2007
    #8
  9. On Sun, 03 Jun 2007 00:12:06 +0200, in comp.lang.c , Richard
    <> wrote:

    >Tor Rustad <> writes:
    >
    >> 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
    Mark McIntyre, Jun 3, 2007
    #9
  10. Tor Rustad Guest

    Richard wrote:
    > Tor Rustad <> 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>
    Tor Rustad, Jun 3, 2007
    #10
  11. Army1987 Guest

    "Robert Gamble" <> ha scritto nel messaggio
    news:...

    >> 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.
    Army1987, Jun 3, 2007
    #11
  12. On Jun 3, 11:16 am, "Army1987" <> wrote:
    > "Robert Gamble" <> ha scritto nel messaggionews:...
    >
    > >> 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
    Robert Gamble, Jun 3, 2007
    #12
  13. On Sun, 03 Jun 2007 21:55:10 -0000, in comp.lang.c , Robert Gamble
    <> wrote:

    >On Jun 3, 11:16 am, "Army1987" <> wrote:
    >> "Robert Gamble" <> ha scritto nel messaggionews:...
    >>
    >> >> 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
    Mark McIntyre, Jun 3, 2007
    #13
  14. On Jun 3, 6:04 pm, Mark McIntyre <> wrote:
    > On Sun, 03 Jun 2007 21:55:10 -0000, in comp.lang.c , Robert Gamble
    >
    >
    >
    > <> wrote:
    > >On Jun 3, 11:16 am, "Army1987" <> wrote:
    > >> "Robert Gamble" <> ha scritto nel messaggionews:...

    >
    > >> >> 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
    Robert Gamble, Jun 3, 2007
    #14
  15. On Sun, 03 Jun 2007 22:22:49 -0000, in comp.lang.c , Robert Gamble
    <> wrote:

    >On Jun 3, 6:04 pm, Mark McIntyre <> wrote:
    >> On Sun, 03 Jun 2007 21:55:10 -0000, in comp.lang.c , Robert Gamble
    >>
    >>
    >>
    >> <> wrote:
    >> >On Jun 3, 11:16 am, "Army1987" <> wrote:
    >> >> "Robert Gamble" <> ha scritto nel messaggionews:...

    >>
    >> >> >> 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
    Mark McIntyre, Jun 3, 2007
    #15
  16. "Army1987" <> writes:
    > "Robert Gamble" <> ha scritto nel messaggio
    > news:...
    >>> 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) <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, Jun 4, 2007
    #16
  17. In article <>,
    Keith Thompson <> 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.
    Richard Tobin, Jun 4, 2007
    #17
  18. pete Guest

    Keith Thompson wrote:
    >
    > "Army1987" <> writes:
    > > "Robert Gamble" <> ha scritto nel messaggio
    > > news:...
    > >>> 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
    pete, Jun 4, 2007
    #18
  19. On Jun 3, 6:35 pm, Mark McIntyre <> wrote:
    > On Sun, 03 Jun 2007 22:22:49 -0000, in comp.lang.c , Robert Gamble
    >
    >
    >
    > <> wrote:
    > >On Jun 3, 6:04 pm, Mark McIntyre <> wrote:
    > >> On Sun, 03 Jun 2007 21:55:10 -0000, in comp.lang.c , Robert Gamble

    >
    > >> <> wrote:
    > >> >On Jun 3, 11:16 am, "Army1987" <> wrote:
    > >> >> "Robert Gamble" <> ha scritto nel messaggionews:...

    >
    > >> >> >> 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, Jun 4, 2007
    #19
  20. Robert Gamble <> writes:

    > On Jun 3, 6:35 pm, Mark McIntyre <> wrote:
    >> On Sun, 03 Jun 2007 22:22:49 -0000, in comp.lang.c , Robert Gamble
    >> <> wrote:
    >> >On Jun 3, 6:04 pm, Mark McIntyre <> wrote:
    >> >> On Sun, 03 Jun 2007 21:55:10 -0000, in comp.lang.c , Robert Gamble

    >>
    >> >> <> wrote:
    >> >> >On Jun 3, 11:16 am, "Army1987" <> wrote:
    >> >> >> "Robert Gamble" <> ha scritto nel messaggionews:...

    >>
    >> >> >> >> 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 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
    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 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.
    Ben Bacarisse, Jun 4, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jim Schueler

    Tricky AUTOLOAD behavior

    Jim Schueler, Aug 25, 2004, in forum: Perl
    Replies:
    1
    Views:
    437
  2. VB Programmer

    Tricky Question: Page_Load

    VB Programmer, Jun 30, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    333
    VB Programmer
    Jun 30, 2003
  3. Replies:
    9
    Views:
    532
    CBFalconer
    Apr 25, 2006
  4. Replies:
    18
    Views:
    217
    Joe Smith
    Oct 5, 2005
  5. Uncle_Fester
    Replies:
    9
    Views:
    256
    Amelia
    Oct 9, 2006
Loading...

Share This Page