What Defins the "C" Language?

[Bart]

An architect is designing a house for you. She asks you, "How large shall
I make the master bedroom." You reply, "I leave it unspecified." So she
makes it 10x15. Then you say, "That's too small."

Local regulations may give guidelines for architects to design houses
without specifying the exact dimensions of each. But for safety or
other considerations may specify the master bedrooms as not less than
10x15 feet.

For bed makers, carpet makers and so on that's more useful - and
practical - than bedrooms that could be 1x1 feet upwards.

Similarly for small, medium and large bedrooms, without giving actual
sizes, regs can specify small<=medium<=large.

Bart C

 

[Dan Pop]

An architect is designing a house for you. She asks you, "How large shall
I make the master bedroom." You reply, "I leave it unspecified." So she
makes it 10x15. Then you say, "That's too small."

OTOH, if you reply: "it shouldn't be smaller than 12x16", do you call this
a "specification" or a "constraint"? The C standard does not specify the
ranges of the integer types, it only imposes certain constraints on them.

Better to follow the advice of Quintilian:

One should not aim at being possible to understand, but at being
impossible to misunderstand.

With certain people (e.g. Mark McIntyre) this is impossible to achieve.

Dan

 

[Bart]

What about a 62-bit byte? MPJ

Unlikely. I started programming on a 36-bit word addressed machine. To
handle text efficiently meant packing 5x7-bit chars to a word and was
a nightmare. I think one old machine (CDC 6600?) used 60-bit words but
in those days text processing was second to numeric work.

An 8-bit byte was a perfect, symmetric size to handle 7-bit ASCII
text, for scaling to 16 and 32 bits, or packing BCD. I think a 'byte'
should mean 8-bits whatever happens in future.

Future machines I think will either stay 8-bit addressable or change
to 16-bits addressable for character handling (ASCII or Unicode)
(physical memory is already 64-bits addressable).

For a low-level language like C it should be possible to know when
programming how many bits you are dealing with.

I think the designers of the standard had in mind being able to expand
ints from 32 to 64 bits or chars from 8 to 16 bits when they left the
word-lengths undefined, nothing weird, and perhaps to keep C usable on
small microprocessors with odd word sizes.

Bart C.

 

[Xenos]

On Thu, 2 Dec 2004 09:49:01 -0600, "Merrill & Michele"

An 8-bit byte was a perfect, symmetric size to handle 7-bit ASCII
text, for scaling to 16 and 32 bits, or packing BCD. I think a 'byte'
should mean 8-bits whatever happens in future.

If you explicitly mean 8-bits then use "octet."

Future machines I think will either stay 8-bit addressable or change
to 16-bits addressable for character handling (ASCII or Unicode)
(physical memory is already 64-bits addressable).

You are implying that all current machine use 8-bit bytes. There are more
computers out there than just PCs. Ever had to program a DSP?

DrX

 

[Richard Tobin]

You are implying that all current machine use 8-bit bytes. There are more
computers out there than just PCs. Ever had to program a DSP?

This is true, but you exaggerate: you don't have to restrict yourself
to PCs to only encounter 8-bit bytes.

Sometimes I think it would be useful to document a "profile" of C that
applies to reasonable modern general-purpose computers: flat address
space, no trap representations, 2s complement arithmetic, power-of-2
byte and short/int/long sizes, ascii-superset and so on. This would
provide an agreed target for the wide range of C programs which are
strictly speaking non-conforming but in practice portable.

-- Richard

 

[Xenos]

This is true, but you exaggerate: you don't have to restrict yourself
to PCs to only encounter 8-bit bytes.

I didn't intend to exaggerate, nor imply that there weren't 8-bit processors
outside of the PC realm. My only point was that many programmers seem to
(in my opinion) to have a pc-centric view, and don't realize that there are
a lot of systems that do not conform to that architecture. I don't see how
you can infer from my previous statement that I thought 8-bit processors
were exclusive to the PC.

DrX

 

[Dan Pop]

If you explicitly mean 8-bits then use "octet."

You are implying that all current machine use 8-bit bytes. There are more
computers out there than just PCs. Ever had to program a DSP?

He was merely talking about machines designed for hosted computing.

Freestanding computing on processors designed for embedded control
applications is a world of its own, that shouldn't be mixed up with
general purpose computing.

Dan

 

[Dan Pop]

Sometimes I think it would be useful to document a "profile" of C that
applies to reasonable modern general-purpose computers: flat address
space, no trap representations, 2s complement arithmetic, power-of-2
byte and short/int/long sizes, ascii-superset and so on. This would
provide an agreed target for the wide range of C programs which are
strictly speaking non-conforming but in practice portable.

This is what happens de facto in the open source computing world.
You won't find many software packages that work on machines with
non-octet bytes, 16-bit int's or non-linear address spaces. So, it is
not realistical to expect any vendor to come up with a general purpose
computer breaking any of the quasi-universal assumptions. It has
always been hard to sell computers without a serious software base,
today it's harder than ever.

Dan

 

[Dan Pop]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

more ^^^^
I didn't intend to exaggerate, nor imply that there weren't 8-bit processors
outside of the PC realm. My only point was that many programmers seem to
(in my opinion) to have a pc-centric view, and don't realize that there are
a lot of systems that do not conform to that architecture. I don't see how
you can infer from my previous statement that I thought 8-bit processors
were exclusive to the PC.

The implication is straightforward, if you reread your first two sentences
above. You're strongly suggesting that computers that aren't PC's don't
use 8-bit bytes.

Dan

 

[Xenos]

The implication is straightforward, if you reread your first two sentences
above. You're strongly suggesting that computers that aren't PC's don't
use 8-bit bytes.

I honestly don't see the inference and it definitely was not my intent, but
I will endeavor to be more clear in the future.

Thanks.

 

[Thomas Stegen]

The implication is straightforward, if you reread your first two sentences
above. You're strongly suggesting that computers that aren't PC's don't
use 8-bit bytes.

The implication cannot be made from the two sentences above. Though
humans do have trouble with stuff like that. "We should improve our
structure" is often interpreted as someone saying the structure is bad
when that is not the case at all.

Same thing above. Ghost nots and all.

 

[Chris Croughton]

I didn't intend to exaggerate, nor imply that there weren't 8-bit
processors outside of the PC realm.

That is, however, what you did imply. IBM have used 8-bit bytes from
the mid 1960s, DEC since the PDP-11, etc. Most of the manufacturers who
have used other sizes haven't called them 'bytes'.

My only point was that many programmers seem to (in my opinion) to
have a pc-centric view, and don't realize that there are a lot of
systems that do not conform to that architecture. I don't see how you
can infer from my previous statement that I thought 8-bit processors
were exclusive to the PC.

Perhaps because you said "There are more computers out there than just
PCs", implying that only PCs have 8 bit bytes. Very few of the
computers in the real world have anything other than 8 bit bytes now
(apart from some dinosaurs, most of those with other byte sizes are in
embedded systems), and few of them are programmed much in C. Indeed,
most of the software available in source form will break (often
horribly) if the byte size is different.

Chris C

 

[Xenos]

On Fri, 3 Dec 2004 10:03:48 -0500, Xenos
That is, however, what you did imply.

Not that I disagree with anything you said, but this is kind of a pet peeve
of mine: I did not imply anything, as you and others have stated. When you
interpret what I say a certain way, it is not that I am implying, it is that
you are inferring. That may lead you to make assumptions about what--if
any--implication I was making, but it is still your inference. Again,
though, I will attempt to be more clear in the future.


Regards.

 

[Randy Yates]

OTOH, if you reply: "it shouldn't be smaller than 12x16", do you call this
a "specification" or a "constraint"?

Is my point not clear enough?
--
% Randy Yates % "How's life on earth?
%% Fuquay-Varina, NC % ... What is it worth?"
%%% 919-577-9882 % 'Mission (A World Record)',
%%%% <[email protected]> % *A New World Record*, ELO
http://home.earthlink.net/~yatescr

 

[Chris Hills]

In Harbison and Steele's text (fourth edition, p.111)
it is stated,

The C language does not specify the range of integers that the
integral types will represent, except ot say that type int may not
be smaller than short and long may not be smaller than int.

They go on to say,

Many implementations represent characters in 8 bits, type short in
16 bits, and type long in 32 bits, with type int using either 16 or
32 bits depending on the implementation. ISO C requires
implementations to use at least these widths.

If the C language is not defined by ISO C, then what defines it?

In reality the answer is quite simple. The users define the language....

That is to say various organisations produce compilers. These are used
by the SW community. Some become dominant in certain fields. ie PC, MAC,
Unix, 8051, AVR, PIC. These dominant compilers are effectively "the
standard" for that area. Most have extensions and some restrictions to
the ISO language .

You will often see the term "NQC" used here. It stands for "Not Quite C"
It refers to the many implementations of C, often for some of the
smaller 8/16 embedded architectures, that are literally Not Quite [ISO]
C but are the "standard" C for that field of work or particular
processor.

When C was originally devised, as commented on in this thread, there
were many machines with sizes that were not 8/16/32. No one was really
sure where things were going so the language was not restricted. Besides
there is not point in gratuitously breaking current code bases.

As time goes on I expect that 99.999% of new processors will have the
nice 8/16/32/64 bit system but there are many systems out there with a
good few years of life in them that don't conform to this.

The ISO-C standard is the goal to which the core of all compilers should
aim for. It is also the specification that they should list deviations
from. The fact that a compiler does not conform is usually not important
as long as you know that it does not and of course how it does not. In
many fields portability is not a prime, or even major, consideration.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Stephen Sprunk]

That is, however, what you did imply. IBM have used 8-bit bytes from
the mid 1960s, DEC since the PDP-11, etc. Most of the manufacturers who
have used other sizes haven't called them 'bytes'.

There have been enough that called non-8-bit units "bytes" that the term
"octet" is preferred in uses where the distinction is critical (e.g.
networking).

8-bit bytes have become so dominant that "byte" and "octet" are often used
interchangeably, but that's obviously not accurate on some systems that most
folks would not consider "mainstream" or "normal".

S

 

[Keith Thompson]

I think the designers of the standard had in mind being able to expand
ints from 32 to 64 bits or chars from 8 to 16 bits when they left the
word-lengths undefined, nothing weird, and perhaps to keep C usable on
small microprocessors with odd word sizes.

One problem is that expanding sizes beyond char=8, short=16, int=32
leaves holes in the type system. If you have char=16, there's no
8-bit type, which makes it difficult to deal with octet-oriented data.
If you leave char=8 but you want int=64 (the natural size on modern
64-bit systems), you can pick either short=16 or short=32, but not
both.

C99's extended integer types, along with the typedefs in <stdint.h>,
could help to address this, but I still get the feeling that any types
other than the predefined ones are always going to be second-class
citizens.

I wouldn't mind allowing types like short short, long long long, et
al. This would allow "int" to be the natural word size, while
permitting a full range of types shorter and longer than int. There
are still some open questions, like whether all implementations are
required to have a "short short" and how far you extend the system.

It might make more sense to redesign the type system from scratch, but
the resulting language arguably wouldn't be C.

 

[Chris Croughton]

There have been enough that called non-8-bit units "bytes" that the term
"octet" is preferred in uses where the distinction is critical (e.g.
networking).

Yes, true (and I have used 'octet' as a type in a lot of my own code).
However, the point is that 8 bit bytes are not at all "PC-centric", a
programmer could have worked on many different machines for decades,
using only 8 bit bytes (as indeed I have, I have never worked with any
machine where something called a 'byte' was other than 8 bits; I've
worked on some where the minimum storage elelent was other than 8 bits
but it was called a 'character', 'half word' or in the case of a 12 bit
machine a 'word'). In particular, I've never worked on a machine with a
C compiler that used other than 8 bit bytes. I've worked on NCR,
Elliott, ICL, IBM, DEC, HP and Sun systems -- and on micros of various
kinds -- over the last 30 years...

8-bit bytes have become so dominant that "byte" and "octet" are often used
interchangeably, but that's obviously not accurate on some systems that most
folks would not consider "mainstream" or "normal".

As I said, a few non-mainstream (now) machines, but most of their
manufacturers don't call them 'bytes' (9 bit bytes, yes, on 36 bit
machines, but I've never heard any DSP programmer call a 32 or 24 bit
word a 'byte', or even a 12 bit one, it sounds silly).

Chris C

 

[Chris Hills]

If the C language is not defined by ISO C, then what defines it?

I found this in another NG in response to a question on C89 it seems
portent to this discussion.


Merrill & Michele wrote:
Unix is a family of operating systems, Macintoshes are
computers made by Apple, and PC clones are computers
based on Intel x86-compatible processors. There were
many other computer platforms before any of those
existed, there are many other platforms today, and
there will be many other platforms in the future.
The C standard tries to accommodate all reasonable
target (execution) platforms, not just certain
selected ones in wide use at a given moment of time.

The 1989 ANSI C standard is not just a reflection of
particular implementations, but of a useful abstract
facility that, from the experience and judgment of
the participants in the process, could without undue
contortions be implemented for all major known
platforms and on most others that might be reasonable
targets for C programs.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Keith Thompson]

I found this in another NG in response to a question on C89 it seems
portent to this discussion.


Merrill & Michele wrote:
Unix is a family of operating systems, Macintoshes are
computers made by Apple, and PC clones are computers
based on Intel x86-compatible processors. There were
many other computer platforms before any of those
existed, there are many other platforms today, and
there will be many other platforms in the future.
The C standard tries to accommodate all reasonable
target (execution) platforms, not just certain
selected ones in wide use at a given moment of time.

The 1989 ANSI C standard is not just a reflection of
particular implementations, but of a useful abstract
facility that, from the experience and judgment of
the participants in the process, could without undue
contortions be implemented for all major known
platforms and on most others that might be reasonable
targets for C programs.

The quoted text was actually written by Doug Gwyn in response to
something posted by "Merrill & Michele". It was in comp.std.c in the
"influences to C89" thread (which "Merrill & Michele" started by
quoting without attribution something *I* wrote here in comp.lang.c).