Determine which sum is larger

R

Richard Heathfield

Philip Potter said:

Except in the unlikely case that his implementation specifies void
main() as an acceptable prototype.

No, he only specified "a 32-bit system", not a specific implementation. And
in any case he'd be hard-pressed to *find* an implementation that
documents void main within its formal conformance documentation. We've
tried to count such implementations before now and, as far as I can
remember, there weren't *any* the last time we looked.
 
B

Bart

Bart said:

...but this line means that your program's behaviour is not governed by the
rules of C.

Sorry I tried hard to remember how to declare the main() entry point
properly, but even after several years of lurking in this newgroup, I
don't actually know.

After trying a few arbitrary combinations I find that int main(void)
gives no compiler warnings (even though I don't explicitly return an
int).

My program still gives the wrong result however.

Bart

#include <stdio.h>

int main(void)
{
unsigned int a,b;

a=3000000000;
b=2000000000;

printf("A = %u\n",a);
printf("B = %u\n",b);
printf("A+B = %u\n",a+b);
}
 
S

santosh

Bart said:
Sorry I tried hard to remember how to declare the main() entry point
properly, but even after several years of lurking in this newgroup, I
don't actually know.

The Standard requires hosted implementations to define the following two
signatures for main():

int main(void) { ... }

int main(int argc, char *argv[]) { ... }

Obviously 'argc' and 'argv' can have any legal name, though these two
are the canonical ones. Also '**argv' is an alternative for '*argv[]'.
After trying a few arbitrary combinations I find that int main(void)
gives no compiler warnings (even though I don't explicitly return an
int).

You should return an int value from main() for your program to be
conforming. To be strictly conforming the return value has to be one
among the set: 0, EXIT_SUCCESS, EXIT_FAILURE. The two macros are
defined in stdlib.h.
My program still gives the wrong result however.

Bart

#include <stdio.h>

int main(void)
{
unsigned int a,b;

a=3000000000;
b=2000000000;

An unsigned int is guaranteed to hold values in the range 0... 65535
only. That's because they need not be more than two bytes.

Use unsigned long to hold values till 4294967295 and (with C99 support)
unsigned long long for values upto 18446744073709551615.
 
R

Richard Heathfield

Bart said:

My program still gives the wrong result however.

Bart

#include <stdio.h>

int main(void)
{
unsigned int a,b;

a=3000000000;
b=2000000000;

printf("A = %u\n",a);
printf("B = %u\n",b);
printf("A+B = %u\n",a+b);

return 0;

What is your implementation's value of UINT_MAX? And what result are you
getting? For instance, if UINT_MAX is 4294967295 on your implementation,
you should expect the result of the addition to be 705032704 (which is
5000000000 modulo 4294967296, which - as someone has already explained to
you in this thread - is how unsigned integer arithmetic is done in C). If
your program displays some other result (for that value of UINT_MAX), then
you do indeed have a problem.
 
R

Richard Heathfield

santosh said:

An unsigned int is guaranteed to hold values in the range 0... 65535
only. That's because they need not be more than two bytes.

No, it is because they need not be more than sixteen bits.
 
S

santosh

Richard Heathfield said:
santosh said:



No, it is because they need not be more than sixteen bits.

Oops. I stand corrected. For a moment I forgot that C's conception
of "byte" is not the same as the widely held one.
 
R

Richard Heathfield

santosh said:
Oops. I stand corrected. For a moment I forgot that C's conception
of "byte" is not the same as the widely held one.

Which widely held one? There are several, but most share the common feature
that a byte is the smallest addressable unit of storage, and this is very
close to C's conception of "byte".
 
S

santosh

Richard Heathfield said:
santosh said:


Which widely held one?

Specifically, the one that believes that a byte is eight bits.
There are several, but most share the common
feature that a byte is the smallest addressable unit of storage, and
this is very close to C's conception of "byte".

This too, but I think that the eight bits bytes conception is a very
common one with programmers only exposed to recent micro and mini
computer systems. The fact that TCP/IP defines bytes as eight bits wide
also contributes to this view.
 
P

Philip Potter

Richard said:
Philip Potter said:



No, he only specified "a 32-bit system", not a specific implementation. And
in any case he'd be hard-pressed to *find* an implementation that
documents void main within its formal conformance documentation. We've
tried to count such implementations before now and, as far as I can
remember, there weren't *any* the last time we looked.

Nevertheless, there is always the possibility - however unlikely - that
Bart is using an implementation which documents void main() within its
formal conformance document. And if so, his program's behaviour *is*
governed by the rules of C.
 
B

Bart

What is your implementation's value of UINT_MAX? And what result are you
getting? For instance, if UINT_MAX is 4294967295 on your implementation,
you should expect the result of the addition to be 705032704 (which is
5000000000 modulo 4294967296, which - as someone has already explained to
you in this thread - is how unsigned integer arithmetic is done in C). If
your program displays some other result (for that value of UINT_MAX), then
you do indeed have a problem.

UINT_MAX is as expected. And the result 705032704 is exactly what I
would have expected last week. And what I would expect to happen
anywhere else I was using 32-bit unsigned arithmetic.

I just have a problem with this slightly chaotic result (705,032,704
is somewhat different from 5,000,000,000) not being due to 'Overflow'.
5 billion needs 33 bits, it overflows 32 bits.

Truncating such results to 32 bits and ignoring CPU flags seems
perfectly reasonable for a compiler to do with integer arithmetic. But
it is clearly an overflow.

For C to state that unsigned values can't overflow (because the
Standard defines unsigned arithmetic in a certain way) seems
misleading.

And it is clearly an issue in the original problem, (a+b)>(c+d). C has
just redefined the problem to be modulo arithmetic rather than
overflow.

Bart
 
R

Richard Heathfield

santosh said:
Specifically, the one that believes that a byte is eight bits.

Oh, that one. (There are others, of course.)
This too, but I think that the eight bits bytes conception is a very
common one with programmers only exposed to recent micro and mini
computer systems.

Yes, it is - but of course there are lots of common misconceptions, of
which that is but one.
The fact that TCP/IP defines bytes as eight bits wide
also contributes to this view.

Do you have a cite? I thought it defined eight-bit objects as octets.
 
R

Richard

santosh said:
Specifically, the one that believes that a byte is eight bits.


This too, but I think that the eight bits bytes conception is a very
common one with programmers only exposed to recent micro and mini
computer systems. The fact that TCP/IP defines bytes as eight bits wide
also contributes to this view.

Of course it is. A "byte" is synonymous with 8 bits in most
instances. Sure, other sizes have and do exist but the "widely held"
belief is indeed that a byte is 8 bits.

The wikipedia page has a reasonable discourse on its usage and its
history over the years which is well written and easy to follow.

http://en.wikipedia.org/wiki/Byte
 
P

Philip Potter

Bart said:
UINT_MAX is as expected. And the result 705032704 is exactly what I
would have expected last week. And what I would expect to happen
anywhere else I was using 32-bit unsigned arithmetic.

I just have a problem with this slightly chaotic result (705,032,704
is somewhat different from 5,000,000,000) not being due to 'Overflow'.
5 billion needs 33 bits, it overflows 32 bits.

Truncating such results to 32 bits and ignoring CPU flags seems
perfectly reasonable for a compiler to do with integer arithmetic. But
it is clearly an overflow.

For C to state that unsigned values can't overflow (because the
Standard defines unsigned arithmetic in a certain way) seems
misleading.

And it is clearly an issue in the original problem, (a+b)>(c+d). C has
just redefined the problem to be modulo arithmetic rather than
overflow.

You've hit the nail on the head here. It is (arguably) misleading to
state that it is not overflow, but this is what the Standard says. It is
even more misleading to deviate from the Standard's usage of language
when talking about C.
 
R

Richard Heathfield

Philip Potter said:

Nevertheless, there is always the possibility - however unlikely - that
Bart is using an implementation which documents void main() within its
formal conformance document. And if so, his program's behaviour *is*
governed by the rules of C.

Not on my system, it isn't. :)
 
R

Richard Heathfield

Bart said:

I just have a problem with this slightly chaotic result
Understandable.

(705,032,704 is somewhat different from 5,000,000,000)

Not mod 4294967296, it isn't.
not being due to 'Overflow'.

Nevertheless, it is not due to overflow.
5 billion needs 33 bits, it overflows 32 bits.

But you weren't calculating 5 billion. You were calculating 705032704. You
just didn't realise it.
Truncating such results to 32 bits and ignoring CPU flags seems
perfectly reasonable for a compiler to do with integer arithmetic. But
it is clearly an overflow.

Not according to the C Standard, which states in 6.2.5(9):

"A computation involving unsigned operands can never overflow, because a
result that cannot be represented by the resulting unsigned integer type
is reduced modulo the number that is one greater than the largest value
that can be represented by the resulting type."
For C to state that unsigned values can't overflow (because the
Standard defines unsigned arithmetic in a certain way) seems
misleading.

I can see why you might think so. Nevertheless, that is how C defines
unsigned integer arithmetic, whether we like it or not.
And it is clearly an issue in the original problem, (a+b)>(c+d). C has
just redefined the problem to be modulo arithmetic rather than
overflow.

If you like, yes. But you can think of modulo arithmetic as being not so
much a problem as an opportunity.
 
J

J. J. Farrell

santosh said:
Specifically, the one that believes that a byte is eight bits.
...
The fact that TCP/IP defines bytes as eight bits wide
also contributes to this view.

But TCP/IP definitely doesn't define bytes as eight bits wide; it avoids
using 'byte' when the number of bits matter. In common with most things
which talk about things which are explicitly 8 bits wide, it uses
'octet'. It defines 'octet' as 'an eight bit byte'.
 
O

Old Wolf

No, he only specified "a 32-bit system", not a specific implementation. And
in any case he'd be hard-pressed to *find* an implementation that
documents void main within its formal conformance documentation. We've
tried to count such implementations before now and, as far as I can
remember, there weren't *any* the last time we looked.

The help system in the IDE for Turbo C (the old version)
included sample programs with void main(), and the
compiler did indeed accept them. Does that count as
documentation?
 
P

Peter Nilsson

santosh said:
You should return an int value from main() for your program
to be conforming.

Even a FORTRAN program is conforming.
To be strictly conforming the return value has to be one
among the set: 0, EXIT_SUCCESS, EXIT_FAILURE.

That's if you bother returning a value.

Unless the program uses the return value from a recursive call
to main, you won't break strict conformance by not returning
a value.

Unlike C++, C does not require a non void function to return
a value, unless that value is used in the expression that
invoked the function.

In the case of the original call to main(), the worst that
happens is that (in C90) an undefined status will be returned
to the host.

You can argue that such a status might format your harddisk,
but there's nothing in the C standards that precludes a host
from doing that on receipt of a successful termination.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,481
Members
44,900
Latest member
Nell636132

Latest Threads

Top