size and range of int in c

[Dik T. Winter]

I omit the largely off-topic parts, leaving only one slightly on-topic
entry:

> The rejection of the excluded middle is echoed in Dijkstra's belief
> that testing can NEVER prove bug absence.

Wrong. The belief that testing can NEVER prove bug absence comes from the
mathematical belief that testing can not prove a theorem over an infinite
set of objects. If has absolutely nothing to do with the rejection of the
excluded middle.

 

[Phil Carmody]

I was just about to slap Aatu for encouraging him...

*Bzzt* Assumption of presence of object without evidence thereof.

but the cloud had a silver lining.

Phil

 

[spinoza1111]

I omit the largely off-topic parts, leaving only one slightly on-topic
entry:

...
 > The rejection of the excluded middle is echoed in Dijkstra's belief
 > that testing can NEVER prove bug absence.

Wrong.  The belief that testing can NEVER prove bug absence comes from the
mathematical belief that testing can not prove a theorem over an infinite
set of objects.  If has absolutely nothing to do with the rejection of the
excluded middle.

Poetically, it does, and poetically it matters, because people who do
not realize that they think in metaphors make the worst kind of
mistakes. Furthermore, Dijkstra's assertion DOES have to do with
excluded middle, since a tested program that seems to work either
works or does not work according to the non-intuitionist, but is in a
third state according to the intuitionist.

The non-intuitionist reasons

(w|~w) & ~~w, therefore w

where ~~w means it hasn't failed. Sure, he isn't *really* using EM
correctly but that's the problem with non-intuitionism. The non-
intuitionist believes that truth can be known independent of proof,
and then proved.

Your lack of imagination is no argument.

Furthermore, you make as a result a mathematical error. Insofar as
intuitionism is a collection of axioms, lemmas, and theorems, each one
of them has quite a lot to do with each other.

"Imagination is more important than knowledge" - Einstein

 

[dk]

That is not the correct range of an int in a C implementation.
You might be thinking of unsigned char.

The range of int is, at a minimum, -32767 to 32767, which requires
2 bytes. Some implementations decide to use 4 bytes for an int,
with a correspondingly larger range.


sizeof(int) == 4 is not guaranteed, but it may be true in your
implementation.


These bytes are not "extra".

Size of int is -32,768 to +32,767 and NOT -32,767 to +32,767.

 

[Noob]

Size of int is -32,768 to +32,767 and NOT -32,767 to +32,767.

No.

The range of an int variable is INT_MIN to INT_MAX inclusive.

The values given below shall be replaced by constant expressions
suitable for use in #if preprocessing directives. Their
implementation-defined values shall be equal or greater in magnitude
(absolute value) to those shown, with the same sign.

* minimum value for an object of type int
INT_MIN -32767

* maximum value for an object of type int
INT_MAX +32767

 

[Richard Tobin]

The range of int is, at a minimum, -32767 to 32767

[/QUOTE]

Size of int is -32,768 to +32,767 and NOT -32,767 to +32,767.

A 16-bit int will typically have that range, because virtually all
systems now use twos complement, but the statement was about the
minimum range required by the C standard.

-- Richard

 

[Seebs]

Size of int is -32,768 to +32,767 and NOT -32,767 to +32,767.

Note that he said "at a minimum".

There exist platforms where it's the latter, not the former. And platforms
where it's roughly +/- 2^31, as well as platforms where it's +/- 2^63 or so.

If they're two's complement, the range is -2^(N-1) to 2^(N-1) - 1. If they're
not, it might be symmetrical, with two representations for zero.

-s

 

[Flash Gordon]

Note that he said "at a minimum".

There exist platforms where it's the latter, not the former. And platforms
where it's roughly +/- 2^31, as well as platforms where it's +/- 2^63 or so.

If they're two's complement, the range is -2^(N-1) to 2^(N-1) - 1. If they're
not, it might be symmetrical, with two representations for zero.

If it's two's complement, the standard allows it to be a symetric range
with one trap representation. I'm sure there must have been at least one
implementation where this was true, and I can see why it could be useful
on a DSP (there can be issues caused by an asymmetric range for some
types of signal processing, and hardware limiting arithmetic to the
symmetric range could be very useful). I don't know if there are still
any systems around with two's complement and a symmetric range.

 

[Keith Thompson]

If it's two's complement, the standard allows it to be a symetric
range with one trap representation. I'm sure there must have been at
least one implementation where this was true, and I can see why it
could be useful on a DSP (there can be issues caused by an asymmetric
range for some types of signal processing, and hardware limiting
arithmetic to the symmetric range could be very useful). I don't know
if there are still any systems around with two's complement and a
symmetric range.

Creating such an implementation would be as simple as modifying the
definition of INT_MAX in <limits.h>. Trap representations don't
actually have to trap.

 

[Dik T. Winter]

>
> Poetically, it does, and poetically it matters, because people who do
> not realize that they think in metaphors make the worst kind of
> mistakes. Furthermore, Dijkstra's assertion DOES have to do with
> excluded middle, since a tested program that seems to work either
> works or does not work according to the non-intuitionist, but is in a
> third state according to the intuitionist.

I do not think mathematicians, whether they are intuitionists or not, consider
"working programs".

> The non-intuitionist reasons
>
> (w|~w) & ~~w, therefore w
>
> where ~~w means it hasn't failed.

In *mathematics* a non-intuitionist reasons (where P is a proposition):
~~P -> P
for an intuitionist there is no such rule.

But also in mathematics there is a rule that if the set of cases is infinite
that there is *no* way to prove a proposition about it by testing individual
case only, and *that* is similar to the testing of programs.

> The non-
> intuitionist believes that truth can be known independent of proof,
> and then proved.

You are wrong.

> Furthermore, you make as a result a mathematical error. Insofar as
> intuitionism is a collection of axioms, lemmas, and theorems, each one
> of them has quite a lot to do with each other.

Right. So what? In intuitionism ~~P -> P is not an inference rule, but
it is in non-intuitionism.

 

[Nick Keighley]

 > The rejection of the excluded middle is echoed in Dijkstra's belief
 > that testing can NEVER prove bug absence.

Wrong.  The belief that testing can NEVER prove bug absence comes from the
mathematical belief that testing can not prove a theorem over an infinite
set of objects.  If has absolutely nothing to do with the rejection of the
excluded middle.

I know this Dijkstra quote get trotted out a lot, but is it actually
true? Computers don't actually deal in infinite sets. So in principle
I can enumerate all cases. This may be practically impossible for
large or complex programs but it can be done in some cases. Therefore
the "never" above (which isn't in Dijkstra's quote) is not true.

 

[Nick Keighley]

[...] The range of int is no less than (-32767,32767)...
Yes, which is just as bad as old Visual Basic. In VB 3.0 you had to
code around "integers" restricted to this range and strings whose
length was similarly restricted.
So C is a usable language for safe programming how?

you use int if you know the range is "small" and long if it's large
and long long if it's very large.


I think it is, but I think he's largely self taught. I make a lot of
pronounciation errors because my reading vocabulary is larger than my
spoken vocabulary (and my deduce-pronounciation-from-spelling
algorithm is broken).

I'll thank you to stop asking this question. It is stupid, and MOST
offensive to the many non-native ESL students who are more intelligent
and better at English than you.

you can often distinguish a native from a non-native writer though.

No. But it does require the programmer to be at least aware of
numerical analysis in a way that an architecture with virtual memory
and variable-length integers would not. As it happens, -2^64..2^64-1
is more than enough,

for what? It's well short of the number of protons in the universe or
even the number of protons in the earth.

but as it happens, intelligent programmers (of
whose number very few are left) use a misnamed "Hungarian" (which was
not invented by Charles Szymonyi)

thats Charles Simonyi

So, who did invent "hungarian notation"?

to make numerical precision an
internal property and not an accident of a variable, since it's
important to know the limits up front.

what?

 

[Nick Keighley]

I can answer that, using what passes for his reasoning:

1) all clear statements are true
2) therefore all unclear statements are false
3) everything he says is unclear
4) therefore everything he says is false

isn't there therefore a paradox?

 

[Nick Keighley]

Yes. A tremendous amount of time has been wasted in useless
"competition" that would have been better spent meeting real human
needs such as clean water and education.

perhaps some sort of central bureau could be used to coordinate
everything. Has anyone ever tried this?

 

[Nick Keighley]

On Tue, 17 Nov 2009 03:39:55 GMT, "Dik T. Winter" <[email protected]>


They don't?

I for one thank Bill for my clean water

 

[Seebs]

I think it is, but I think he's largely self taught. I make a lot of
pronounciation errors because my reading vocabulary is larger than my
spoken vocabulary (and my deduce-pronounciation-from-spelling
algorithm is broken).

As long as we're talking about English, the only way you can be sure an
algorithm for that is broken would be if it DOESN'T produce incorrect
results.

-s

 

[Nobody]

I know this Dijkstra quote get trotted out a lot, but is it actually
true? Computers don't actually deal in infinite sets. So in principle
I can enumerate all cases. This may be practically impossible for
large or complex programs but it can be done in some cases. Therefore
the "never" above (which isn't in Dijkstra's quote) is not true.

You would still have to prove that you had enumerated over the entire set
of "inputs".

E.g. for a Unix program, there's no way that you could enumerate over the
entire set of possible combinations for argv[] and environ[] and kernel
state and hardware state and ..., so you would need to demonstrate that
the variables over which you had enumerated represented the entire set of
factors which could affect the program's behaviour.

For a C function e.g. "int foo(int x)", you could enumerate over the range
of "int" (provided that it's no larger than 32 bits; won't work on ILP64),
but you would still need to demonstrate that the function doesn't depend
upon global variables.

OTOH, for a function "int foo(double x)", even if you could prove
that nothing other than the parameter x affected the function's return
value, you still couldn't enumerate over the range of a typical "double".

 

[Kaz Kylheku]

I know this Dijkstra quote get trotted out a lot, but is it actually
true? Computers don't actually deal in infinite sets. So in principle

In Usenet, it's even the case that non-testing can prove the absence of
functionality. E.g. ``I know nothing about that <editor/os/programming
language> but I know it's broken and it sucks.

I can enumerate all cases.

Dijkstra might say to that: if you are able to test a hypothesis for all
possible combinations of all of its inputs, then you are not really testing any
more, but proving.

If a particular space is small enough to succumb to this approach, then in fact
that approach falls into the domain of formal verification.

By analogy, enumerating all values of the boolean variables in a simple logical
argument, to build an exhaustive truth table, is one of the formal ways of
proving or disproving that it's valid; it's different from software
testing.

This may be practically impossible for
large or complex programs but it can be done in some cases. Therefore

But it's practically impossible for even small programs! The combinatorial
explosion in the input space grows rather fast.

If there are four independent inputs that are 32 bits wide, you have 128 bits.

Also, you really have to be sure that you are exhaustively testing the space.
Certain bugs can increase the space. If the program invokes undefined
behaviors, how do you know they don't explode the space?

For instance, accessing some uninitialized memory of 32 bits might not appear
as an obvious input to your program, but it could potentially blow up your
state space by a factor of 2^32.

And then of course are programs with real-time behavior, where no test
case is 100% repeatable, even if you build a detailed simulation of
the system (which will be necessarily a discrete simulation).

 

[Nick Keighley]

You would still have to prove that you had enumerated over the entire set
of "inputs".

For certain functions thats trivial.

E.g. for a Unix program, there's no way that you could enumerate over the
entire set of possible combinations for argv[] and environ[] and kernel
state and hardware state and ..., so you would need to demonstrate that
the variables over which you had enumerated represented the entire set of
factors which could affect the program's behaviour.

Err maybe. But in the real world you can prove that certain functions
are ONLY called with a finite set of inputs. Sure if you take that
function outside of its framework thats a totally different issue.

That was probably Dijkstra's point. You need to prove something about
the program. There a programs where I could easily demonstrate that
argv[] and environ[] if I also assume my platform is working then I
can exhaustivly test small programs.

If you regard testing as an automatic way of proving certain
properties about a program then the Dijkstras have less reason for
dismissing it. Look at the TDD people.

it will work it'll just take a long time...

Well. That's easy enough. or you comment the legal inputs and assume its
only called with them. if you want you can man trap the entry point to
simply return a safe return code if the inputs are not in range.

or use assert(), another handy automatic verification tool.

But you could test it for a few numbers within a certain limit of float
and declare it works in that range. If you suggest to me there might be
a subtle bug only on 2.339058309583905890 then we might as well give
up....

you haven't used Intel hardware have you?

http://en.wikipedia.org/wiki/Pentium_FDIV_bug

I'd be *much* warier about enumerating all possibilities once floating
point was added into the mix. I'd be less certain about my proofs too.

 

[Nick Keighley]

In








Yes, of course there is. Did I not mention that I was using /his/
reasoning?

but but that would mean he either had an inconsistent set of
postulates or his inference rules were faulty!