What Defins the "C" Language?

[Dan Pop]

If I were designing C from scratch, or even if I were working on the
C89 standard (via time machine), I might propose something like this:

1. Drop the word "byte" altogether.

2. Define a type "storage_unit" (or pick a shorter name if you like)
as the fundamental addressible memory unit. On typical systems, a
storage_unit is an 8-bit unsigned type with no padding bits; on
others, it might be bigger, or even smaller. The mem*() functions
work on arrays of storage_unit. The type "storage_unit*" might even
replace "void*"; malloc() could return a "storage_unit*". Add
implicit conversions to taste (or don't).

3. Define the type "char" independently of the "storage_unit" type.
sizeof(char) needn't be 1. Strings are arrays of char. (I'm glossing
over issues of signed vs. unsigned, and of 8-bit vs. 16-bit vs. 32-bit
character sets. We might eventually want "long char" rather than
"wchar_t".)

4. Since the natural size of a storage_unit might be bigger than the
natural size of a character, we need some way to deal with arrays of
sub-storage_unit elements. Perhaps some arrays could be explicitly
packed, as in Pascal and Ada. Packed structs could eliminate the need
for explicit bit fields. The sizeof operator might need to yield the
size in bits rather than in storage units.

A far more complicated design than the current one. Where are the
redeeming advantages?

Although having the type char practically tied to the architecture's byte
looks like a source of potential problems, those problems consistently
failed to materialise in practice. wchar_t, wide character constants
and string literals are available right there, for anyone needing them.

Dan

 

[Dan Pop]

A specification rarely if ever specifies everything exactly. A plan might
specify dimensions as particular values but not precise materials,
construction methods etc.

It specifies *everything* the client is interested in. This could include
precise materials and construction methods, if the client so desires.

A specification is made up of a collection of
constraints, some may be exact others not. Is the C language standard as
a whole a specification?

Nope, it's a partial specification. Key features are left to the
implementor to specify and others are left unspecified. The C standard is
worthless, as a specification, to any program whose output depends on the
results of floating-point operations:

4 The accuracy of the floating-point operations (+, -, *, /)
and of the library functions in <math.h> and <complex.h> that
return floating-point results is implementation-defined,
as is the accuracy of the conversion between floating-point
internal representations and string representations performed
by the library routines in <stdio.h>, <stdlib.h>, and <wchar.h>.
The implementation may state that the accuracy is unknown.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So the answer to your question is probably "both".

I don't think so. A bunch of constraints could constitute a
specification, a constraint alone is not enough.

Dan

 

[Lawrence Kirby]

On Thu, 09 Dec 2004 13:38:46 +0000, Dan Pop wrote:

....

Although having the type char practically tied to the architecture's byte
looks like a source of potential problems, those problems consistently
failed to materialise in practice. wchar_t, wide character constants
and string literals are available right there, for anyone needing them.

True, but look at the bloat in the C99 standard library that results from
having char and wchar_t.

Lawrence

 

[Dan Pop]

On Thu, 09 Dec 2004 13:38:46 +0000, Dan Pop wrote:

...


True, but look at the bloat in the C99 standard library that results from
having char and wchar_t.

It's unavoidable, if you want to support two character sizes, which, in
turn, it's unavoidable in a language like C at this particular moment of
time, when supporting wide character sets *only* is not a realistic
option.

Dan

 

[Lawrence Kirby]

It specifies *everything* the client is interested in.

If only that were true.

In my experience this is rarely if ever the case.

This could include
precise materials and construction methods, if the client so desires.

Yes it could, but if it doesn't that doesn't stop it being a specification.

Nope, it's a partial specification. Key features are left to the
implementor to specify and others are left unspecified.

But it does specify things, which in the simplest terms makes it a
specification.

The C standard
is worthless, as a specification, to any program whose output depends on
the results of floating-point operations:

Whether it is fit for any particular purpose is not relevant to whether it
is a specification or not.

4 The accuracy of the floating-point operations (+, -, *, /)
and of the library functions in <math.h> and <complex.h> that
return floating-point results is implementation-defined, as is the
accuracy of the conversion between floating-point internal
representations and string representations performed by the library
routines in <stdio.h>, <stdlib.h>, and <wchar.h>. The
implementation may state that the accuracy is unknown.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


I don't think so. A bunch of constraints could constitute a
specification, a constraint alone is not enough.

What's the minimum number of constraints needed to qualify as a
specification?

Lawrence

 

[Dan Pop]

If only that were true.

In my experience this is rarely if ever the case.


Yes it could, but if it doesn't that doesn't stop it being a specification.


But it does specify things, which in the simplest terms makes it a
specification.

It depends on what you actually need specified. A specification that
doesn't cover relevant areas of importance for you is not a specification
at all for you, even if it is a perfectly good specification for someone
else, primarily interested in other areas, much better covered by the
specification.

Whether it is fit for any particular purpose is not relevant to whether it
is a specification or not.

Again, it depends on what you actually need specified. For anyone
interested in using C for numerical analysis purposes, the C standard is
not a specification.

What's the minimum number of constraints needed to qualify as a
specification?

It depends on what's being specified. A programming language
specification requires more than one for toothpicks.

Dan

 

[Albert van der Horst]

I think Doug Gwyn pushed for decoupling type "char" from the
fundamental addressing unit while the original ANSI C standard was
being developed; the rest of the committee didn't go for it.

The ANSI Forth standard introduced the "addressing unit" besides
char. Interestingly there is no standard way to address (fetch something
from) an addressing unit, only to fetch from characters (and the natural
machine width, say int). It would be interesting to have a standard
where this is properly addressed.
In practice a lot of programs assume that a char is an addressing unit,
and is equal to a byte, and that pointers converted to integers
differ by one in consequitive bytes. At least in Forth your program
is "conforming" to the standard if you "declare" an environmental
dependancy to this effect.

I guess in C such a program is just non-standard, and the best you
can do is warn users that it only runs under such and so conditions,
and prevent the programs from actually running by using
asserts.

And yes, it's far too late to do any of this, at least for any
language named "C" (and there are already too many languages named
"D").

C is not alone ...

Groetjes Albert

 

[Keith Thompson]

In practice a lot of programs assume that a char is an addressing unit,
and is equal to a byte, and that pointers converted to integers
differ by one in consequitive bytes. At least in Forth your program
is "conforming" to the standard if you "declare" an environmental
dependancy to this effect.

I guess in C such a program is just non-standard, and the best you
can do is warn users that it only runs under such and so conditions,
and prevent the programs from actually running by using
asserts.

In C, a char is equal to a byte; that's the definition of "byte".
If the following:
assert(sizeof(char) == 1);
fails, it's the implementation that's broken.

On the other hand, converting a pointer to an integer yields an
implementation-defined (or is it unspecified?) result, depending on
how the underlying system represents addresses (and, in some cases, on
what extra magic the compiler performs to fit the C model). Pointers
converted to integers to differ by one in consecutive bytes on moor
systems, but there's rarely any good reason for a program to make that
assumption. If you want to do arithmetic on pointers, just do pointer
arithmetic.

(Testing pointer alignment is one case where this kind of thing can be
useful, but there's no portable way to do it.)