Standard integer types vs <stdint.h> types

[dj3vande]

Just to make it clear, I did not say "real" I said "float".

Correct. *I* said "real", as an illustration. To make it clear that
that was my purpose, I even introduced it by mentioning the context I
was using for the illustration, which was not the context of the point
I was addressing with the illustration.


[much snippage]

Uh ... its not just an isomorphism, its a bijection complete with all
the operations.

Uh... That's what an isomorphism *IS*.

Whatever, this is *actually* (uncontroversially for once) off
topic; try sci.math .

If my intention were to discuss the math and not merely to use it to
illustrate my objection to Richard H's claims in the discussion about
C, I wouldn't've posted it to comp.lang.c in the first place.

I'm not making an argument about representation.

Had you read the paragraph you quoted for comprehension, you would have
noticed that not only was I not claiming you were, I was in fact
specifically claiming you *weren't*.

I think it's time to put you back in my killfile; you're smart enough
to be worth listening to when you're talking about something you know,
but you're not nearly wise enough to be worth arguing with when you're
not.


dave

 

[CJ]

In maths N is a subset of R, by the way.

Not according to any standard definitions of N and R, though for sure
there is a canonical injection from N to R.

 

[Paul Hsieh]

Correct. *I* said "real", as an illustration.

As did Richard Harter who started this mischaracterization of my
position. If you and Richard want to talk about reals, then you can't
turn around and claim you are not being off topic here on comp.lang.c.

[...] To make it clear that
that was my purpose, I even introduced it by mentioning the context I
was using for the illustration, which was not the context of the point
I was addressing with the illustration.

[much snippage]

Uh ... its not just an isomorphism, its a bijection complete with all
the operations.

Uh... That's what an isomorphism *IS*.

Isomorphisms don't include the "<" operator. Its exactly the same
thing right down to the axioms, not just a mapping of the algebras.

Isomorphisms are algebra preserving; that's all. So if I created a
mapping of f:x->cos(x)+i*sin(x), and then define + and * to make it an
isomorphism, that's fine. But if I then defined "<" on it to compare
the real parts of this translation, then the post mapped set isn't
really the integers anymore.

This distinction is important since the given ordering of the integers
is an important property of them.

If my intention were to discuss the math and not merely to use it to
illustrate my objection to Richard H's claims in the discussion about
C, I wouldn't've posted it to comp.lang.c in the first place.

Richard H seems to have made a mistake in characterizing what I said,
and you followed him. Either way, talking about reals is not on topic
here.

Had you read the paragraph you quoted for comprehension, you would have
noticed that not only was I not claiming you were, I was in fact
specifically claiming you *weren't*.

You said: "It seems to have been clear (to everybody but you) that the
original
claim was intended to be taken this way, and not to claim that the
representation is identical."

But I don't claim them *just* to be an isomorophism of integers,
because in the C language "<" is also correctly represented in
floating point integers in exactly the same way. In addition the cast
operator is value preserving (within compatible range limits) amongst
different *types* of integers in the C language. They are not just a
mapping of integers, they *ARE* integers.

Richard Heathfield's bizarre counter argument amounts to saying that
double is a different type than int, while ignoring that char is also
different from int, as is short or unsigned long.

Perhaps this might make it clearer: Imagine for one second that the
"/" operator in C produced an *INTEGER* result for floating point
types (rounded in the same way that ordinary integer division is) and
that the "%" operator was defined as the remainder after division for
floating point types as well. If so, then the very integer nature of
doubles would be absolutely clear. If you initialized the doubles
with integers, then all sets of arithmetic operations would preserve
their integer nature. You would presumably then protest that you've
lost the ability to divide in the floating point sense, so maybe the C
language people would have added an fdiv() function for that purpose.
Well, my point is that we *HAVE* this situation, only just slightly
transformed: "/" gives you floating point division, and you use
functions like modf() for integer division on floating point. From
the language point of view, this is just a bunch of syntax.

I think it's time to put you back in my killfile; you're smart enough
to be worth listening to when you're talking about something you know,
but you're not nearly wise enough to be worth arguing with when you're
not.

Well, so long as you don't have a mirror, you will continue to assume
that all your conflicts with me are my problem. So its just as well.

 

[Richard Bos]

Rarely.

If I write

int a = 45000;

that will not work in 16 bit implementations.

You HAVE to know the bitsize to know how much data
you can put into an integer!

No, you don't. In fact, bit size can be misleading. Maybe it's a perfect
idea on all the systems you have experience with, but that is no excuse
for not being clearer _and_ more secure at the same time.

Use INT_MAX. It exists for a reason.

Richard

 

[Bart C]

No, you don't. In fact, bit size can be misleading. Maybe it's a perfect
idea on all the systems you have experience with, but that is no excuse
for not being clearer _and_ more secure at the same time.

Use INT_MAX. It exists for a reason.

How would that be used exactly? Something like this (if it's even
possible)?:

#define INT_BIG_ENOUGH_TO_STORE(x).... /* clever macro using INT_MAX*/

Then using it as:

INT_BIG_ENOUGH_TO_STORE(45000) a=45000;

Or are you suggesting just looking at the limits and choosing the correct
int based on that? That would only work for this implementation.

 

[jacob navia]

How would that be used exactly? Something like this (if it's even
possible)?:

#define INT_BIG_ENOUGH_TO_STORE(x).... /* clever macro using INT_MAX*/

Then using it as:

INT_BIG_ENOUGH_TO_STORE(45000) a=45000;

Or are you suggesting just looking at the limits and choosing the correct
int based on that? That would only work for this implementation.

I mean if I have some data (like 45 000) how the hell I am supposed to
know if the implementation supports that unless I use can hold that?

Better use the C99 solution and be safe. That was my idea.

 

[Flash Gordon]

Malcolm McLean wrote, On 20/01/08 19:40:

Yes. The integer is ultimately used as an index. You mess about with it

That's a totally untypical program.

Based on your definition of what is typical people seem to be able to
come up with more examples of classes of untypical programs than you can
of typical programs.

Most C programs use arrays very
heavily. In fact it is the only basic data structure that has direct
language support.

Last time I looked C had structures.

Sometimes in older C programs you see pointer notation used where array
dereferencing would be clearer, I'll grant you. That's technically an
exception to my point, even though an integer will be used to count down
the travelling pointer.

Or not when traversing a linked list. Or not when traversing a tree. Or
not when there is an end marker. Or not when...

 

[Malcolm McLean]

Malcolm McLean wrote, On 20/01/08 19:40:

Last time I looked C had structures.

A struct is not a basic data structure. It sounds rather silly, but it's
not.

 

[Richard Harter]

A struct is not a basic data structure. It sounds rather silly, but it's
not.

I gather that computer science has been substantially revised in
the recent past.

 

[jacob navia]

I gather that computer science has been substantially revised in
the recent past.

I find this completely ridiculous. When "structs" aren't
data structures what are they then?

UFOs?

 

[Flash Gordon]

Malcolm McLean wrote, On 21/01/08 22:13:

A struct is not a basic data structure. It sounds rather silly, but it's
not.

All depends on your definitions. According to some CAML documentation an
integer is a basic data structure. The same thing according to some
courses using Pascal, for example
http://pages.cpsc.ucalgary.ca/~denzinge/courses/449-winter2004/slides/05-ManipData-handout.pdf

So according to at least some definitions of basic data structures C has
ones other than arrays.

 

[CBFalconer]

I find this completely ridiculous. When "structs" aren't data
structures what are they then?

Notice the word 'basic'. structs could be called compound objects.

 

[Randy Howard]

Malcolm McLean wrote, On 21/01/08 22:13:

All depends on your definitions. According to some CAML documentation an
integer is a basic data structure. The same thing according to some
courses using Pascal, for example
http://pages.cpsc.ucalgary.ca/~denzinge/courses/449-
winter2004/slides/05-Manip
Data-handout.pdf

So according to at least some definitions of basic data structures C has
ones other than arrays.

Once upon a time, stacks and queues were basic data structures. Now we
find out that anything more taxing than an "int" is not basic. ;-)

 

[James Kuyper]

CBFalconer wrote:
Yes, but you can do that in your own stdint.h where the platform does
not provide one (which is what I do).

Well, if the compiling end uses a C99 compiler, you can't replace
<stdint.h> [1], and thus have to use "stdint.h".

No, if the compiling end uses a C99 implementation, the custom stdint.h
would simply end up unused,

There's no such guarantee. 7.1.2p3 says "If a file with the same name as
one of the above < and > delimited sequences, not provided as part of
the implementation, is placed in any of the standard places that are
searched for included source files, the behavior is undefined."

Therefore, it is essential if compiling with a conforming implmentation
of C to make sure that no user-provided file named stdint.h is in any of
the standard places searched for included source files. You can't just
count on it being skipped over (unless you know that this is, in fact,
the form that undefined behavior takes for a particular implementation).

 

[James Kuyper]

I find this completely ridiculous. When "structs" aren't
data structures what are they then?

UFOs?

He's not denying that they aren't data structures, he's denying that
they are basic. The C standard doesn't define such a concept as "basic
data types", but it does say that struct types are derived types.

 

[James Kuyper]

How would that be used exactly? Something like this (if it's even
possible)?:

#define INT_BIG_ENOUGH_TO_STORE(x).... /* clever macro using INT_MAX*/

No, you use conditional compilation of typedefs, of course.

....

Or are you suggesting just looking at the limits and choosing the correct
int based on that? That would only work for this implementation.

Properly written, conditionally compiled typedefs should be quite
adequately portable, though less efficient in C99 than using the
<stdint.h> typedefs.

 

[Harald van Dijk]

Ian Collins wrote:
CBFalconer wrote:
Yes, but you can do that in your own stdint.h where the platform does
not provide one (which is what I do).
Well, if the compiling end uses a C99 compiler, you can't replace
<stdint.h> [1], and thus have to use "stdint.h".

No, if the compiling end uses a C99 implementation, the custom stdint.h
would simply end up unused,

There's no such guarantee. 7.1.2p3 says "If a file with the same name as
one of the above < and > delimited sequences, not provided as part of
the implementation, is placed in any of the standard places that are
searched for included source files, the behavior is undefined."

Therefore, it is essential if compiling with a conforming implmentation
of C to make sure that no user-provided file named stdint.h is in any of
the standard places searched for included source files. You can't just
count on it being skipped over (unless you know that this is, in fact,
the form that undefined behavior takes for a particular implementation).

I was assuming the code would not be compiled from any of the standard
include locations. When it's not, <stdint.h> first searches the standard
include locations, never seeing the custom stdint.h. C90 implementations
without <stdint.h> would search the standard include locations first,
fail to find anything, and then behave as if #include "stdint.h" was used.

The behaviour is not meant to be undefined if a file named stdint.h is
placed in a location searched for #include "..." but not #include <...>,
is it? "Standard places" isn't completely clear, so I'm not entirely sure.

 

[Keith Thompson]

He's not denying that they aren't data structures, he's denying that
they are basic. The C standard doesn't define such a concept as "basic
data types", but it does say that struct types are derived types.

It also says that array types are derived types. The kinds of derived
types are arrays, structures, unions, functions, and pointers; see C99
6.2.5.

Since Malcolm acknowledges that his claim "sounds rather silly",
perhaps he'd care to justify it.

 

[Richard Bos]

Once upon a time, stacks and queues were basic data structures. Now we
find out that anything more taxing than an "int" is not basic. ;-)

I think the real problem here is that anything more taxing than an int
(note: _not_ an integer, specifically an int) is not BASIC.

Richard

 

[Malcolm McLean]

Since Malcolm acknowledges that his claim "sounds rather silly",
perhaps he'd care to justify it.

A struct is a hard-coded associative array. So rather a special beast.
Normally we wouldn't think of it as one of the basic data structures (stack,
queue, linked list, tree, graph and so on) at all.