What is a type?

[jacob navia]

I would like to add at the beginning of the C tutorial I am writing
a short blurb about what "types" are. I came up with the following text.

Please can you comment?
Did I miss something?
Is there something wrong in there?
--------------------------------------------------------------------
Types
A type is a definition for a sequence of storage bits. It gives the
meaning of the data stored in memory. If we say that the object a is an
int, it means that the bits stored at that location are to be understood
as a natural number that is built by consecutive additions of powers of
two. If we say that the type of a is a double, it means that the bits
are to be understood as the IEEE 754 standard sequences of bits
representing a double precision floating point value.

Types can be primitive types (i.e. built-in types) or composite types,
i.e. types built from several primitive types.

Functions have a type too. The type of a function is determined by the
type of its return value, and all its arguments. The type of a function
is its interface with the outside world: its inputs (arguments) and its
outputs (return value).
Types in C can be incomplete, i.e. they can exist as types but nothing
is known about them, neither their size nor their bit-layout. They are
useful for encapsulating data into entities that are known only to
certain parts of the program.
Each type can have an associated pointer type: for int we have int
pointer, for double we have double pointer, etc. We can have also
pointers that point to an unspecified object. They are written as void
*, i.e. pointers to void.

The primitive types in lcc-win32 are:
Type Size in lcc-win32 Standard?
bool 1 Available in C99
char (signed/unsigned) 1 yes
short (signed/unsigned) 2 yes
int (signed/unsigned) 4 yes
long (signed/unsigned) 4 yes
long long 8 Available in C99
float 4 yes
double 8 yes
long double 12 Available in C99
complex types 16 May be absent in some

implementations
qfloat 56 Specific to lcc-win32
bignum variable Specific to lcc-win32

[Richard Bos]

CBFalconer <cb********@yahoo.com> wrote:

Richard Bos wrote:

Not necessarily. The standard headers needn't be available as files;
and even when an implementor wants to make most of his <stdio.h>
legible to the user, nothing need stop him from having it contain
something like

#include <FILE_magic>
#define FILE __FILE_magic_FILE
#define getc __FILE_magic_getc

How does this prevent the snooper from reading FILE_magic? If you
wire those definitions into the compiler, and eliminate the
existence of FILE_magic, then you have given up the flexibility of
revising the actual FILE implementation, causing attendant future
pain.

I'm afraid I don't see that. Yes, you have a bit of code apart from the
publically visible headers, but then, isn't that true for most of the
internals of any implementation? The only problem I see is that it makes
it harder to design the library and the compiler separately, but
nobody's forcing you to go that way.

Richard

[Dan Pop]

In <41***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:

Dan Pop wrote:

CBFalconer <cb********@yahoo.com> writes:

Dan Pop wrote:
Eric Sosman <er*********@sun.com> writes:
> Dan Pop wrote:
>> Keith Thompson <ks***@mib.org> writes:
>>
>>> The type FILE is an odd case. It's intended to act like an opaque
>>> type, in the sense that the user isn't supposed to look inside it --
>>> and a conforming implementation probably could make it a genuine
>>> incomplete type, hiding the actual definition inside the library
>>> implementation.
>>
>> Nope, it cannot.
>>
>> 2 The types declared are size_t (described in 7.17);
>>
>> FILE
>>
>> which is an object type ...
>>
>> An incomplete type is not an object type, so your implementation
>> would be non-conforming.
>
> A substantial amount of hiding is possible even so,
> at the cost of one extra indirection level:
>
> /* <stdio.h> */
> typedef struct __file_magic *FILE;
> ...
>
> `FILE' is now an object type (to wit, a pointer), and that
> much is revealed as required. The nature of what it points
> to, though, remains hidden.

Another way of hiding the internals is:

typedef unsigned char FILE[__file_size];

while the implementation operates with a completely different
definition of FILE, having the property that
sizeof(__internal_FILE) == __file_size.

Even if the two types may not have the same alignment requirements,
no correct C program is going to be affected, because all valid
FILE objects are created by the implementation and are, therefore,
guaranteed to be correctly aligned.

And how do you then implement getc and putc macros, which have to
be expanded in the users code, without incorporating magic numbers
and worse? Conceded you don't have to implement them as macros.
Where does the "without incorporating magic numbers" requirement come
from? The standard headers are already required to define plenty of
magic numbers, like FILENAME_MAX, HUGE_VAL and the whole of <limits.h>
and <float.h>.

... snip about snarky ways to implement it ...

The whole point about making definitions and using them, defining
structures, etc. is to make it easy for the implementor to change
his mind, without destroying the users code. One you start playing
wierd games you make the whole system more error prone.

Nonsense! Every implementation has to play such "weird games" at one
point or another. See the Unix system call numbers, for a typical
example.
We already
have a well known vendor of windowed OSs that does that, with
abysmal results.
Which only proves the incompetence of that vendor.
So "without incorporating magic numbers" is not a requirement, but
just good practice.

Nonsense. If the "magic numbers" serve a well defined purpose and are
correctly handled by the implementor, they don't have any adverse effects
on anything. Furthermore, user code need not even know that they exist.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union