Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #7506 > unrolled thread

what is the output

Back to article view | Back to comp.lang.c

Contents

  what is the output vinay kumar <vinay5b9@gmail.com> - 2011-07-03 09:32 -0700
    Re: what is the output "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> - 2011-07-03 19:43 +0200
    Re: what is the output Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-03 13:47 -0400
      Re: what is the output Keith Thompson <kst-u@mib.org> - 2011-07-03 12:15 -0700
      Re: what is the output Chad <cdalten@gmail.com> - 2011-07-03 13:55 -0700
        Re: what is the output "osmium" <r124c4u102@comcast.net> - 2011-07-03 16:20 -0500
        Re: what is the output Keith Thompson <kst-u@mib.org> - 2011-07-03 14:24 -0700
          Re: what is the output Chad <cdalten@gmail.com> - 2011-07-03 16:13 -0700
            Re: what is the output "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-07-03 21:10 -0400
            Re: what is the output Keith Thompson <kst-u@mib.org> - 2011-07-04 14:22 -0700
            Re: what is the output Todd Carnes <toddcarnes@gmail.com> - 2011-07-05 03:30 +0000
        Re: what is the output John Gordon <gordon@panix.com> - 2011-07-05 02:26 +0000
      Re: what is the output Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-03 18:30 -0700
        Re: what is the output Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-03 21:58 -0400
          Re: what is the output Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-04 17:10 -0700
            Re: what is the output Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-04 21:42 -0400
              Re: what is the output Shao Miller <sha0.miller@gmail.com> - 2011-07-04 22:51 -0400
              Re: what is the output Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-06 16:23 -0700
      Re: what is the output Michael Press <rubrum@pacbell.net> - 2011-07-03 21:23 -0700
    Re: what is the output Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-03 14:06 -0600
    Re: what is the output Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-03 18:19 -0700
      Re: what is the output Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-03 22:12 -0400
        Re: what is the output Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-03 21:16 -0600
      Re: what is the output Keith Thompson <kst-u@mib.org> - 2011-07-04 13:59 -0700
        Re: what is the output Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-04 17:15 -0700
    Re: what is the output Martin Ambuhl <mambuhl@earthlink.net> - 2011-07-04 17:21 -0400
      Re: what is the output Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-04 17:27 -0700
        Re: what is the output Keith Thompson <kst-u@mib.org> - 2011-07-04 18:07 -0700
          Re: what is the output Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-06 17:08 -0700
      Re: what is the output "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-07-04 22:19 -0400
        Re: what is the output Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-04 23:19 -0400
          Re: what is the output Keith Thompson <kst-u@mib.org> - 2011-07-05 08:34 -0700
    Re: what is the output Shao Miller <sha0.miller@gmail.com> - 2011-07-04 18:26 -0400
      Re: what is the output Todd Carnes <toddcarnes@gmail.com> - 2011-07-05 03:36 +0000

Page 2 of 2 — ← Prev page 1 [2]

#7547

vinay kumar <vinay5b9@gmail.com> writes:

> main()
> {
> int d=010;
> printf("%d",d);
> }
>
> Re: what is the output

8

> please give with explanation

You can't take 3 from 2, 2 is less than 3,
so you look at the 4 in the eight's place.
Now that's really four 8's, so you make
it three 8's, change an 8 to 8 ones and
add them to the 2 and that gives 1 2 base 8
which is ten base ten and you take away 3 that's 7.

Now instead of 4 in the 8's place, you've got 3
'cause you added 1 (that is to say, 8) to the 2,
but you can't take 7 from 3, so you look at the 64's.

From the 3 you then use 1 to make 8 1's.  You add
those 1's to the 3 and you get 1 3 (base 8)
or in other words in base ten you have 11,
and you take away 7,
and 7 from 11 is 4.

Now go back to the 64's, you're left with 2
and you take away 1 from 2 and that leaves??
1, that's right.

...

Remember:  base 8 is just like base 10 really..  if
you're missing two fingers.

[toc] | [prev] | [next] | [standalone]

#7553

On 7/3/2011 9:19 PM, Tim Rentsch wrote:
> vinay kumar<vinay5b9@gmail.com>  writes:
>
>> main()
>> {
>> int d=010;
>> printf("%d",d);
>> }
>>
>> Re: what is the output
>
> 8
>
>> please give with explanation
>
> You can't take 3 from 2, 2 is less than 3,
> so you look at the 4 in the eight's place.
> Now that's really four 8's, so you make
> it three 8's, change an 8 to 8 ones and
> add them to the 2 and that gives 1 2 base 8
> which is ten base ten and you take away 3 that's 7.
>
> Now instead of 4 in the 8's place, you've got 3
> 'cause you added 1 (that is to say, 8) to the 2,
> but you can't take 7 from 3, so you look at the 64's.

     "Sixty-four?  How did sixty-four get into this?" I hear you
cry.  Well, sixty-four is eight squared, don't you see?  "Ask a
silly question ..."

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#7556

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 7/3/2011 9:19 PM, Tim Rentsch wrote:
>> vinay kumar<vinay5b9@gmail.com>  writes:
>>
>>> main()
>>> {
>>> int d=010;
>>> printf("%d",d);
>>> }
>>>
>>> Re: what is the output
>>
>> 8
>>
>>> please give with explanation
>>
>> You can't take 3 from 2, 2 is less than 3,
>> so you look at the 4 in the eight's place.
>> Now that's really four 8's, so you make
>> it three 8's, change an 8 to 8 ones and
>> add them to the 2 and that gives 1 2 base 8
>> which is ten base ten and you take away 3 that's 7.
>>
>> Now instead of 4 in the 8's place, you've got 3
>> 'cause you added 1 (that is to say, 8) to the 2,
>> but you can't take 7 from 3, so you look at the 64's.
>
>     "Sixty-four?  How did sixty-four get into this?" I hear you
> cry.  Well, sixty-four is eight squared, don't you see?  "Ask a
> silly question ..."

I used to tell my assembly language students I'd come across a good
video about doing arithmetic in various radixes, and then showing them
"New Math" on youtube.  The results were wonderful:  they had a look of
complete horror when they thought they'd stumbled in to one of those
terrible classes where the professor abdicates the job of delivering
lectures in favor of showing stupid educational videos, with a slow
dawning realization of what they were seeing.....  very few of them had
ever heard of Tom Lehrer before that lecture (sadly), but many of them
came to me over the next few days and weeks telling me about "Poisoning
Pigeons in the Park" and "Vatican Rag".

Mission Accomplished.

[toc] | [prev] | [next] | [standalone]

#7605

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> You can't take 3 from 2, 2 is less than 3,
> so you look at the 4 in the eight's place.
> Now that's really four 8's, so you make
> it three 8's,

... regroup, and you ...

>               change an 8 to 8 ones and
> add them to the 2 and that gives 1 2 base 8
> which is ten base ten and you take away 3 that's 7.
[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#7620

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>> You can't take 3 from 2, 2 is less than 3,
>> so you look at the 4 in the eight's place.
>> Now that's really four 8's, so you make
>> it three 8's,
>
> ... regroup, and you ...
>
>>               change an 8 to 8 ones and
>> add them to the 2 and that gives 1 2 base 8
>> which is ten base ten and you take away 3 that's 7.
> [...]

Right...  stanzas two and three I needed to look up, but the
first stanza I did from (much less than perfect) memory...

[toc] | [prev] | [next] | [standalone]

#7607

On 7/3/2011 12:32 PM, vinay kumar wrote:
> main()
> {
> int d=010;
> printf("%d",d);
> }
>
> please give with explanation

Several diagnostics, since
   a) main incorrectly has no return type (should be int)
   b) printf has no prototype (#include <stdio.h>)
   c) for pre-C99 compilers, main fails to return a value.

[toc] | [prev] | [next] | [standalone]

#7621

Martin Ambuhl <mambuhl@earthlink.net> writes:

> On 7/3/2011 12:32 PM, vinay kumar wrote:
>> main()
>> {
>> int d=010;
>> printf("%d",d);
>> }
>>
>> please give with explanation
>
> Several diagnostics, since
>   a) main incorrectly has no return type (should be int)

Allowed in C90.

>   b) printf has no prototype (#include <stdio.h>)

C90 - no diagnostic required (and will probably work
just fine).

>   c) for pre-C99 compilers, main fails to return a value.

C90 - no diagnostic required, and behavior is defined
(only termination status returned to host environment
is undefined).

[toc] | [prev] | [next] | [standalone]

#7624

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Martin Ambuhl <mambuhl@earthlink.net> writes:
>
>> On 7/3/2011 12:32 PM, vinay kumar wrote:
>>> main()
>>> {
>>> int d=010;
>>> printf("%d",d);
>>> }
>>>
>>> please give with explanation
>>
>> Several diagnostics, since
>>   a) main incorrectly has no return type (should be int)
>
> Allowed in C90.
>
>>   b) printf has no prototype (#include <stdio.h>)
>
> C90 - no diagnostic required (and will probably work
> just fine).

Right.

But strictly speaking, the behavior is still undefined.
The compiler, upon seeing the call, assumes that printf has been
declared as

    int printf(char*, int);

or equivalent; the actual definition is variadic, which means (for
example) that the fimplementation is allowed to use an entirely
different calling sequence.

But in practice, it's going to work on most or all C90
implementations, because any implementation on which it didn't work
would have broken too much existing code.  Even C99 implementations
are likely to (have a mode in which they) let it by with a warning.

>>   c) for pre-C99 compilers, main fails to return a value.
>
> C90 - no diagnostic required, and behavior is defined
> (only termination status returned to host environment
> is undefined).

Right.  But note that, unlike the phrase "undefined behavior", the
standard doesn't say what an undefined termination status means, so we
have to fall back on the English meanings of the words.  The most likely
meaning is that the termination status can be as if main() returned any
arbitrary int value (and the implementation is not required to document
how this value is determined, or even to be consistent about it).

But one could imagine the "termination status" being something other
than an int value -- such as the canonical "suffusion of yellow".

(Since C99 has patched this loophole anyway, we're not going to
see a ruling on this.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#7797

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Martin Ambuhl <mambuhl@earthlink.net> writes:
>>
>>> On 7/3/2011 12:32 PM, vinay kumar wrote:
>>>> main()
>>>> {
>>>> int d=010;
>>>> printf("%d",d);
>>>> }
>>>>
>>>> please give with explanation
>>>
>>> Several diagnostics, since
>>>   a) main incorrectly has no return type (should be int)
>>
>> Allowed in C90.
>>
>>>   b) printf has no prototype (#include <stdio.h>)
>>
>> C90 - no diagnostic required (and will probably work
>> just fine).
>
> Right.
>
> But strictly speaking, the behavior is still undefined.
> [snip elaboration]

Yes, I was mainly commenting on the (implicit) claim that
a diagnostic is required, which it is not.


>>>   c) for pre-C99 compilers, main fails to return a value.
>>
>> C90 - no diagnostic required, and behavior is defined
>> (only termination status returned to host environment
>> is undefined).
>
> Right.  But note that, unlike the phrase "undefined behavior", the
> standard doesn't say what an undefined termination status means, so we
> have to fall back on the English meanings of the words.  The most likely
> meaning is that the termination status can be as if main() returned any
> arbitrary int value (and the implementation is not required to document
> how this value is determined, or even to be consistent about it).
>
> But one could imagine the "termination status" being something other
> than an int value -- such as the canonical "suffusion of yellow".
> [snip C99-related]

If I may summarize, the main point you're making is that a
"termination status that is undefined" could do anything -
any possible behavior might result.  And that conclusion is
correct.

However, as far as the C Standard is concerned, it is also true
that there is just as wide a range of possible behaviors if
'return 0;', 'return EXIT_SUCCESS;', or 'return EXIT_FAILURE;'
is done instead.  No matter what the termination status is, what
might happen after returning to the host environment could be
anything at all - neither the C Standard nor the implementation
has any control over it or anything to say about it.

An implementation could choose to treat 'main()' returning
without an exit value as being the same as 'main()' doing a
'return EXIT_FAILURE;' (or 'return 0;'), but doing that doesn't
limit what the host environment may do upon a return.  At some
level, the point of having the termination status being undefined
when 'main()' doesn't do a return is so that implementations are
free to choose one of these possibilities (or perhaps make no
particular choice at all, which is also their prerogative under
C90).

It is of course possible, in some theoretical sense, that an
operating system could respond to "defined" termination statuses
in a graceful way, and respond to "other" termination statuses
by launching ICBM's or setting the computer on fire.  However,
as far as what the Standard says, it is just as possible that
the reverse would hold.  So an argument that either of these
is an "anything could happen" situation seems pretty weak,
and practically speaking there is likely to be little if any
difference between them.

[toc] | [prev] | [next] | [standalone]

#7627

On Mon, 04 Jul 2011 17:21:38 -0400, Martin Ambuhl <mambuhl@earthlink.net>  
wrote:

> On 7/3/2011 12:32 PM, vinay kumar wrote:
>> main()
>> {
>> int d=010;
>> printf("%d",d);
>> }
>>
>> please give with explanation
>
> Several diagnostics, since
>    a) main incorrectly has no return type (should be int)
>    b) printf has no prototype (#include <stdio.h>)
>    c) for pre-C99 compilers, main fails to return a value.

But since main is not declared with a return type, this lack of a return
shouldn't trigger a diagnostic, should it?
-- 
Morris Keesan -- mkeesan@post.harvard.edu

[toc] | [prev] | [next] | [standalone]

#7633

On 7/4/2011 10:19 PM, Morris Keesan wrote:
> On Mon, 04 Jul 2011 17:21:38 -0400, Martin Ambuhl
> <mambuhl@earthlink.net> wrote:
>
>> On 7/3/2011 12:32 PM, vinay kumar wrote:
>>> main()
>>> {
>>> int d=010;
>>> printf("%d",d);
>>> }
>>>
>>> please give with explanation
>>
>> Several diagnostics, since
>> a) main incorrectly has no return type (should be int)
>> b) printf has no prototype (#include <stdio.h>)
>> c) for pre-C99 compilers, main fails to return a value.
>
> But since main is not declared with a return type, this lack of a return
> shouldn't trigger a diagnostic, should it?

     C99: Yes, because defining a function without specifying a
return type requires a diagnostic.  (The "lack of a return" need
not produce a diagnostic, and is in fact well-defined for hosted
environments because of a vile pandering to sloppy programmers.
But the "not declared with a return type" is verboten.)

     C90: Implementation's discretion.  No diagnostic is required,
but all diagnostics are (as always) permitted.  ("Warning: Code was
written on a Thursday. I never could get the hang of Thursdays.")

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#7665

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 7/4/2011 10:19 PM, Morris Keesan wrote:
>> On Mon, 04 Jul 2011 17:21:38 -0400, Martin Ambuhl
>> <mambuhl@earthlink.net> wrote:
>>> On 7/3/2011 12:32 PM, vinay kumar wrote:
>>>> main()
>>>> {
>>>> int d=010;
>>>> printf("%d",d);
>>>> }
>>>>
>>>> please give with explanation
>>>
>>> Several diagnostics, since
>>> a) main incorrectly has no return type (should be int)
>>> b) printf has no prototype (#include <stdio.h>)
>>> c) for pre-C99 compilers, main fails to return a value.
>>
>> But since main is not declared with a return type, this lack of a return
>> shouldn't trigger a diagnostic, should it?
>
>      C99: Yes, because defining a function without specifying a
> return type requires a diagnostic.  (The "lack of a return" need
> not produce a diagnostic, and is in fact well-defined for hosted
> environments because of a vile pandering to sloppy programmers.
> But the "not declared with a return type" is verboten.)

In fact it's a syntax error.  "main() { ... }" doesn't satisfy
the syntax for a function definition, and a compiler needn't even
recognize it as one.  (Probably most C99 compilers use grammars
that recognize C90-style declarations, for the purpose of producing
meaningful error messages.)

>      C90: Implementation's discretion.  No diagnostic is required,
> but all diagnostics are (as always) permitted.  ("Warning: Code was
> written on a Thursday. I never could get the hang of Thursdays.")

Right.  In C90, a missing return type is equivalent to an explicit
return type of "int".  The declaration is perfectly correct C90
(ignoring an obscure quibble about "main()" vs. "main(void)").

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#7614

On 7/3/2011 12:32, vinay kumar wrote:
> main()
> {
> int d=010;
> printf("%d",d);
> }
>
> please give with explanation

Correct output: 31 Usenet response posts.

Explanation:

[toc] | [prev] | [next] | [standalone]

#7636

On Mon, 04 Jul 2011 18:26:20 -0400, Shao Miller wrote:

> On 7/3/2011 12:32, vinay kumar wrote:
>> main()
>> {
>> int d=010;
>> printf("%d",d);
>> }
>>
>> please give with explanation
> 
> Correct output: 31 Usenet response posts.
> 
> Explanation:

LOL!

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web