Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

C Programming Language

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)?

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+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.
On Jun 2, 12:28 pm, "Army1987" <please.@for.it> wrote:

> <birensubu@gmail.com> ha scritto nel messaggionews:1180772304.807456.242510@n15g2000prd.googlegroups.com...

> [...]

> > 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

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:

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

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:

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

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:

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

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

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.

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:

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

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.

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:

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

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 "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

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,:

    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
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 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
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 un-isolatable entities are arranged.

--
Eric.Sos@sun.com

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc