Re: type Foo_ptr in new void*;

[James Rogers <jimmaureenrogers@worldnet.att.net>]

Tomasz Wegrzanowski wrote:
> 
> In article <3B64C26F.C195B4E0@worldnet.att.net>, James Rogers wrote:
> > Yes, you are correct. C does allow you to forward declare a structure
> > or a pointer without ever completing the definition. This is one of
> > the nasty capabilities "provided" by C. You can even create an array
> > of Foo *. However, pointer arithmetic from the start of this array
> > produces unspecified behavior. What is the sizeof Foo? Since it is
> > undefined, there is no correct answer to that question. Without a
> > proper definition of the sizeof Foo, there can be no reliable pointer
> > arithmetic.
> 
> Correct answer is compilation error.
> It's illegal to do pointer arith on void* or incomplete types.

It is illegal, but not necessarily caught by the compiler.
This means that the correct answer is not compilation error.
C compilers are actually pretty primitive in their understanding of
data type completion. They rely on highly intelligent linkers to
find all the completions. Unfortunately, linker diagnostic messages
are a lot less useful than compiler diagnostic messages. One reason
is that the linker has no understanding of source code line numbers.
It cannot tell you where the problem occured beyond the name of the
object file it came from. Given the C #include technology, you cannot
even directly relate the object file name with the source file name
in all cases. A single object file could have been created from
one or several source files.

Even more problems arise when using shared libraries or DLLs. In
that case the linker cannot find all the required pieces. Only the
program loader will find them. Your compiler and linker may
execute without error. Your loader will be left to try to
identify all the missing pieces. Loader error messages are even
poorer than linker error messages.

What does it mean, then, when a function returns a void*?
You are allowed to cast that void* to any other pointer type you want.
Once cast, you are allowed to perform pointer arithmetic on it.
If you do not TRULY know the type of the data pointed to by a void*,
and then you cast it to some type, expecting correct results, you 
will sometimes get a nasty surprise. Pointer arithmetic will be
performed, but your view of the data will be incorrect due to 
poor alignment problems.

> 
> > In other words, you can declare some wonderful data structures in C
> > based on incomplete type definitions. Unfortunately, a program built
> > upon such a structure is neither reliable nor portable.
> 
> It's both portable and reliable.

It is portable because it causes the same kinds of problems wherever
used. You can rely on this feature to be dangerous. For instance,
an array of incomplete data types, or pointers to the same, will
cause a violation of the rules you state above. That array can be
created, but not manipulated. In C, all array element access
involves pointer arithmetic. This is true even when using array
indexing directly. The compiler simply substitutes pointer arithmetic
for the indexing notation.

> 
> > Ada does not allow you to compile a program with an incomplete type
> > definition. There is no equivalent because the existence of an
> > equivalent to this C capability would only introduce errors in your
> > program. There is nothing positive that can be achieved by allowing
> > a program to be incompletely specified.
> 
> Sure, if your favourite language has no feature X,
> then feature X is useless.

Ada does not have this feature because its danger was judged to 
outweigh its value. That does not make this feature useless. It only
makes it unsafe.

> Incomplete types warrant opacity.

This is important in C because of its lack of private data types.
More modern languages achieve opacity without sacrificing program
safety. 

Jim Rogers
Colorado Springs, Colorado USA