What Defins the "C" Language?

[Randy Yates]

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?
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
ra*********@sonyericsson.com, 919-472-1124

[Thomas Stegen]

Dan Pop wrote:

In <co*********@cui1.lmms.lmco.com> "Xenos" <do**********@spamhate.com> writes:

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> wrote in message
news:co***********@pc-news.cogsci.ed.ac.uk...

In article <co*********@cui1.lmms.lmco.com>,
Xenos <do**********@spamhate.com> wrote:
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?

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

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.

--
Thomas.

[Chris Croughton]

On Fri, 3 Dec 2004 10:03:48 -0500, Xenos
<do**********@spamhate.com> wrote:

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> wrote in message
news:co***********@pc-news.cogsci.ed.ac.uk...

In article <co*********@cui1.lmms.lmco.com>,
Xenos <do**********@spamhate.com> wrote:

>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.

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]

"Chris Croughton" <ch***@keristor.net> wrote in message
news:sl******************@ccserver.keris.net...

On Fri, 3 Dec 2004 10:03:48 -0500, Xenos
<do**********@spamhate.com> wrote:
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]

Da*****@cern.ch (Dan Pop) writes:

In <y8**********@ieee.org> Randy Yates <ya***@ieee.org> writes:

Erik Trulsson <er******@student.uu.se> writes:

Yes, they can. ISO C does not specify *the* range of integers, but it
does specify *a* *minimum* range of integers. Not quite the same thing.

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"?

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)',
%%%% <ya***@ieee.org> % *A New World Record*, ELO
http://home.earthlink.net/~yatescr

[Chris Hills]

In article <xx*************@usrts005.corpusers.net>, Randy Yates
<ra*********@sonyericsson.com> writes

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 /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Stephen Sprunk]

"Chris Croughton" <ch***@keristor.net> wrote in message
news:sl******************@ccserver.keris.net...

On Fri, 3 Dec 2004 10:03:48 -0500, Xenos
<do**********@spamhate.com> wrote:

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> wrote in message
news:co***********@pc-news.cogsci.ed.ac.uk...

In article <co*********@cui1.lmms.lmco.com>,
Xenos <do**********@spamhate.com> wrote:
>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.

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'.

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

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

[Keith Thompson]

Bart <48**@freeuk.com> writes:
[...]

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris Croughton]

On Fri, 3 Dec 2004 16:56:55 -0600, Stephen Sprunk
<st*****@sprunk.org> wrote:

"Chris Croughton" <ch***@keristor.net> wrote in message
news:sl******************@ccserver.keris.net...

On Fri, 3 Dec 2004 10:03:48 -0500, Xenos
<do**********@spamhate.com> wrote:

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> wrote in message
news:co***********@pc-news.cogsci.ed.ac.uk...
In article <co*********@cui1.lmms.lmco.com>,
Xenos <do**********@spamhate.com> wrote:
>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.

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'.

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]

In article <xx*************@usrts005.corpusers.net>, Randy Yates
<ra*********@sonyericsson.com> writes

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 /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Keith Thompson]

Chris Hills <ch***@phaedsys.org> writes:

In article <xx*************@usrts005.corpusers.net>, Randy Yates
<ra*********@sonyericsson.com> writes

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.

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).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Randy Yates]

Chris Hills <ch***@phaedsys.org> writes:

In article <xx*************@usrts005.corpusers.net>, Randy Yates
<ra*********@sonyericsson.com> writes

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.

Thanks, Chris.
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.
True. TI's latest fixed-point, low-power digital signal processor family,
the TMS320C55xx, has a minimum wordlength of 16 bits, so a "byte" (a
sizeof(char)) is 16 bits.

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.

Yeah, I knew all of this. I had just made the statement the other day
in comp.dsp that an int could be any size when someone stated that
they must be at least 16 bits. Then when I opened my H&S to clarify I
got even more confused. I was pretty sure that in the past (WAY
pre-ISO-C) you could have any damn size int you wanted.
--
% Randy Yates % "Though you ride on the wheels of tomorrow,
%% Fuquay-Varina, NC % you still wander the fields of your
%%% 919-577-9882 % sorrow."
%%%% <ya***@ieee.org> % '21st Century Man', *Time*, ELO
http://home.earthlink.net/~yatescr

[Chris Barts]

Randy Yates wrote:

Da*****@cern.ch (Dan Pop) writes:

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?

Our point is that the ISO C standard doesn't exactly specify a lot of
things. It is a contract between the compiler-writer and the compiler-user.

The compiler-writer promises to meet all of the minimums imposed by the
ISO C standard and adhere to all of the definitions for library
functions and control structures. He essentially promises to make an
implementation of the C virtual machine on whatever hardware platform
his compiler targets.

The compiler-user promises to write conformant, sensible code that the
compiler can translate into useful actions (machine code output,
usually). He essentially promises to not exceed the limitations of the C
virtual machine, as described in the ISO C standard.

(Note that the C virtual machine usually isn't implemented as a virtual
machine in the Java sense. It is, rather, a set of implicit assumptions
that a guaranteed to be valid in any C program.)

[Chris Hills]

In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
[e-mail]> writes

Chris Hills <ch***@phaedsys.org> writes:

In article <xx*************@usrts005.corpusers.net>, Randy Yates
<ra*********@sonyericsson.com> writes

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.

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).

Thanks for the clarification on attributions.
My apologies to Doug for missing him off

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Preben Traerup]

>

True. TI's latest fixed-point, low-power digital signal processor family,
the TMS320C55xx, has a minimum wordlength of 16 bits, so a "byte" (a
sizeof(char)) is 16 bits.

Sure?

I would expect something like
sizeof(char) = 1;
and
CHAR_BIT = 16;

[Randy Yates]

Preben Traerup <pr***********@ericsson.com> writes:

True. TI's latest fixed-point, low-power digital signal processor family,
the TMS320C55xx, has a minimum wordlength of 16 bits, so a "byte" (a
sizeof(char)) is 16 bits.

Sure?

I would expect something like
sizeof(char) = 1;
and
CHAR_BIT = 16;

You are correct. My writing was not clear. I should have written "a 'byte' (a char)...".
It is always true that sizeof(char) = 1 on any platform.
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
ra*********@sonyericsson.com, 919-472-1124

[Dan Pop]

In <vf**********@ieee.org> Randy Yates <ya***@ieee.org> writes:

Da*****@cern.ch (Dan Pop) writes:

In <y8**********@ieee.org> Randy Yates <ya***@ieee.org> writes:

Erik Trulsson <er******@student.uu.se> writes:

Yes, they can. ISO C does not specify *the* range of integers, but it
does specify *a* *minimum* range of integers. Not quite the same thing.

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"?

Is my point not clear enough?

Apparently, you completely missed mine.

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

[Dan Pop]

In <m3************@Claudio.Messina> Mark L Pappin <ml*@acm.org> writes:

Somebody (attribution over-zealously trimmed) wrote:

TI's latest fixed-point, low-power digital signal processor family,
the TMS320C55xx, has a minimum wordlength of 16 bits, so a "byte" (a
sizeof(char)) is 16 bits.

and Preben Traerup <pr***********@ericsson.com> followed-up with:

Sure?

I would expect something like
sizeof(char) = 1;
and
CHAR_BIT = 16;

You seem to be under the misapprehension that what you said is at odds
with what you quoted.

No such misapprehension: sizeof(char) cannot be simultaneously 16 and 1,
so the two statements are at odds.
Granted, you did use terminology within the language.

Not really. His semicolons suggest valid C statements, but they aren't
valid C statements.

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

[Dan Pop]

In <1102115185.oclYzrsWlRSD1yMTvSBOeQ@teranews> "Stephen Sprunk" <st*****@sprunk.org> writes:

"Chris Croughton" <ch***@keristor.net> wrote in message
news:sl******************@ccserver.keris.net...

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

Can we have some concrete examples? AFAIK, the term "byte" was made
popular by the IBM 360, an 8-bit byte machine. It wouldn't make much
sense in a word-addressed machine, anyway.
(e.g. networking).
"Byte", being defined as a computer memory unit, wouldn't make much sense
in a networking context in the first place.
8-bit bytes have become so dominant that "byte" and "octet" are often used
interchangeably,
Not in English, as far as I can tell. The term "byte" is still used in a
computer memory context, while "octet" is reserved for networking
contexts. The French have a strong preference for "octet", because of
their rampant NIH syndrome.
but that's obviously not accurate on some systems that most
folks would not consider "mainstream" or "normal".

Systems without a native definition of "byte" in the first place.
It's the definition of byte provided by C for those systems that you're
talking about. The redefinition of "byte" in the C standard was a gross
mistake: the standard doesn't really need it, "character" is good enough
for its purposes and the term "byte" already had a well established
meaning in computing.

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

[Joona I Palaste]

Dan Pop <Da*****@cern.ch> scribbled the following:

In <m3************@Claudio.Messina> Mark L Pappin <ml*@acm.org> writes:

Somebody (attribution over-zealously trimmed) wrote:

TI's latest fixed-point, low-power digital signal processor family,
the TMS320C55xx, has a minimum wordlength of 16 bits, so a "byte" (a
sizeof(char)) is 16 bits.
and Preben Traerup <pr***********@ericsson.com> followed-up with:

Sure?

I would expect something like
sizeof(char) = 1;
and
CHAR_BIT = 16;

You seem to be under the misapprehension that what you said is at odds
with what you quoted.

No such misapprehension: sizeof(char) cannot be simultaneously 16 and 1,
so the two statements are at odds.

Granted, you did use terminology within the language.

Not really. His semicolons suggest valid C statements, but they aren't
valid C statements.

"Somebody" obviously doesn't understand C syntax, but his point is
easily understood, and correct. sizeof(char) is always 1, no matter the
circumstances. CHAR_BIT is the number of bits in a C byte. A C byte
does not have to have 8 bits, it can have more, but it can't have less.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"My absolute aspect is probably..."
- Mato Valtonen

[Stephen Sprunk]

"Dan Pop" <Da*****@cern.ch> wrote in message
news:cp***********@sunnews.cern.ch...

In <1102115185.oclYzrsWlRSD1yMTvSBOeQ@teranews> "Stephen Sprunk"
<st*****@sprunk.org> writes:

There have been enough that called non-8-bit units "bytes" that the term
"octet" is preferred in uses where the distinction is critical

Can we have some concrete examples? AFAIK, the term "byte" was made
popular by the IBM 360, an 8-bit byte machine. It wouldn't make much
sense in a word-addressed machine, anyway.

(e.g. networking).

"Byte", being defined as a computer memory unit, wouldn't make much sense
in a networking context in the first place.

IBM's ESCON uses 10-bit bytes to this day; I don't know if that qualifies as
networking (I was referring mainly to TCP/IP) since that's just a connection
between two mainframes or between a mainframe and a FEP...

Also, back when TCP/IP was originally specified, there were many machines
expected to run the protocol that did not natively use 8-bit memory units; I
wasn't around at the time so I don't know first-hand if they used "byte" to
describe 9-bit (or other sized) memory locations, but there was apparently
enough (mis)use of the word to justify inventing another one. Discussions
here and on comp.arch lead me to believe that non-8-bit units were (and
still are) commonly called bytes on some architectures.

8-bit bytes have become so dominant that "byte" and "octet" are often used
interchangeably,

Not in English, as far as I can tell. The term "byte" is still used in a
computer memory context, while "octet" is reserved for networking
contexts.

I would think that, prior to widespread networking, there was no need for
"octets" because data residing on one machine was rarely (compared to today)
moved to another machine, particularly one with a different size. If
machines had different byte (or whatever) sizes, it was largely irrelevant.
Now that networks are ubiquitous, nearly all mainstream machines use 8-bit
bytes and so octet has fallen back out of use.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:
[...]

It's the definition of byte provided by C for those systems that you're
talking about. The redefinition of "byte" in the C standard was a gross
mistake: the standard doesn't really need it, "character" is good enough
for its purposes and the term "byte" already had a well established
meaning in computing.

In my opinion, there were two errors: the redefinition of "byte", and
the close association of bytes and characters.

It would have been better to avoid the word "byte" altogether, use
something like "storage unit" to refer to the fundamental unit of
addressible memory, and not require a character to be one byte.

I think it also would have been good to allow arrays of quantities
smaller than a storage unit (such as arrays of 8-bit characters on
systems that can only directly address 64-bit words, and bit arrays on
all systems). This would require some extra work for the compiler,
and some would argue that it wouldn't be in the "spirit of C".

But I'm just daydreaming; none of this is likely to happen in any
future language with the name "C".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Preben Traerup <pr***********@ericsson.com> writes:

True. TI's latest fixed-point, low-power digital signal processor family,
the TMS320C55xx, has a minimum wordlength of 16 bits, so a "byte" (a
sizeof(char)) is 16 bits.

Sure?

I would expect something like
sizeof(char) = 1;
and
CHAR_BIT = 16;

Strictly speaking, sizeof(char) == 1 by definition, but it's not
entirely unreasonable to say informally that "sizeof(char) is 16
bits". It's a matter of expressing the same quantity in different
units. (My argument is weakened by the fact that the result of the
sizeof operator is always in bytes, but the meaning is clear enough.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dan Pop]

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

Da*****@cern.ch (Dan Pop) writes:
[...]

It's the definition of byte provided by C for those systems that you're
talking about. The redefinition of "byte" in the C standard was a gross
mistake: the standard doesn't really need it, "character" is good enough
for its purposes and the term "byte" already had a well established
meaning in computing.
In my opinion, there were two errors: the redefinition of "byte", and
the close association of bytes and characters.

My point was that "byte" was not needed at all by the C standard, since
"character" could have been used instead.
It would have been better to avoid the word "byte" altogether, use
something like "storage unit" to refer to the fundamental unit of
addressible memory, and not require a character to be one byte.
You don't need to bother at all with the fundamental unit of addressable
memory in the C standard, if all the types have sizes that are multiples
of char, so sizeof(char) == 1 still holds.

OTOH, in a low level language like C, it would be unreasonable not to give
access to the programmer to the fundamental unit of addressable memory...
After all, C itself was designed to port Unix from a word-addressed
architecture (the PDP-7) to a byte-addressed architecture (the PDP-11).
I think it also would have been good to allow arrays of quantities
smaller than a storage unit (such as arrays of 8-bit characters on
systems that can only directly address 64-bit words,
The implementor can always support that and we both know one concrete
example.
and bit arrays on all systems).
To have that, you need the type "bit". Introducing this type involves
a redesign of the sizeof operator. And we both know it is too late for
that...
This would require some extra work for the compiler,
and some would argue that it wouldn't be in the "spirit of C".

It's no more work than bit-fields require, so the spirit of C can't be
invoked. The nasty problem is the sizeof operator, that was not designed
with bits in mind.

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

[Dan Pop]

In <1102452927.2c9acc563ab75ba87df2f506af05214e@teran ews> "Stephen Sprunk" <st*****@sprunk.org> writes:

Also, back when TCP/IP was originally specified, there were many machines
expected to run the protocol that did not natively use 8-bit memory units; I
wasn't around at the time so I don't know first-hand if they used "byte" to
describe 9-bit (or other sized) memory locations,
There were NO 9-bit memory locations and, hence, no 9-bit "bytes". Those
machines used 36-bit memory locations (they were word-addressed machines,
not byte-addressed machines) and 36-bit general purpose registers. It was
only the data in a GPR that could be interpreted as a sequence of
characters of fixed or variable size.

Other word sizes that were popular among non-byte addressable machines
are 12, 18 and 60 (for supercomputers). Cray-1 (and its successors) was
some kind of a weirdo with 64-bit addressable words, but this proved to
be quite fortunate for C implementors.
but there was apparently
enough (mis)use of the word to justify inventing another one. Discussions
here and on comp.arch lead me to believe that non-8-bit units were (and
still are) commonly called bytes on some architectures.

The point is that there were no non-8-bit units of memory; before the
IBM 360 and the PDP-11 the unit of memory was the word which was
indivisible (atomic) as far as the memory system was concerned.

This is why I asked about concrete examples of machines using non-octet
bytes.

8-bit bytes have become so dominant that "byte" and "octet" are often used
interchangeably,

Not in English, as far as I can tell. The term "byte" is still used in a
computer memory context, while "octet" is reserved for networking
contexts.

I would think that, prior to widespread networking, there was no need for
"octets" because data residing on one machine was rarely (compared to today)
moved to another machine, particularly one with a different size. If
machines had different byte (or whatever) sizes, it was largely irrelevant.
Now that networks are ubiquitous, nearly all mainstream machines use 8-bit
bytes and so octet has fallen back out of use.

The 8-bit byte was imposed by the success of of hardware architectures
like IBM 360, PDP-11 and i8080A long before TCP/IP networking became
widespread. It's more reasonable to assume that TCP/IP networking adopted
octets because most machines that were going to be connected already had
8-bit bytes. The use of the term octet was justified by the fact that
some of the machines didn't have any kind of (well defined) byte, the
most important example back then being the PDP-10 machine (36-bit words
which could be divided, in software, in a sequence of variable size
characters).

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

[Richard Tobin]

In article <cp**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote:

Other word sizes that were popular among non-byte addressable machines
are 12, 18 and 60 (for supercomputers).

And 24. The ICL 1900 series and compatibles used that. It was
typically used with a 6-bit character set, 4 to a word.

-- Richard

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

Da*****@cern.ch (Dan Pop) writes:
[...]

It's the definition of byte provided by C for those systems that you're
talking about. The redefinition of "byte" in the C standard was a gross
mistake: the standard doesn't really need it, "character" is good enough
for its purposes and the term "byte" already had a well established
meaning in computing.

In my opinion, there were two errors: the redefinition of "byte", and
the close association of bytes and characters.

My point was that "byte" was not needed at all by the C standard, since
"character" could have been used instead.

It would have been better to avoid the word "byte" altogether, use
something like "storage unit" to refer to the fundamental unit of
addressible memory, and not require a character to be one byte.

You don't need to bother at all with the fundamental unit of addressable
memory in the C standard, if all the types have sizes that are multiples
of char, so sizeof(char) == 1 still holds.

You're still assuming that the fundamental unit of addressable memory
has to be a character. C requires that, of course, and that's not
going to change, but I'm suggesting that it would have been better to
keep them separate.

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.

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.

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").

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Lawrence Kirby]

On Fri, 03 Dec 2004 13:36:09 +0000, Dan Pop wrote:

In <y8**********@ieee.org> Randy Yates <ya***@ieee.org> writes:

Erik Trulsson <er******@student.uu.se> writes:

Yes, they can. ISO C does not specify *the* range of integers, but it
does specify *a* *minimum* range of integers. Not quite the same thing.

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.

A specification rarely if ever specifies everything exactly. A plan might
specify dimensions as particular values but not precise materials,
construction methods etc. 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?

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

Lawrence

[Dan Pop]

In <cp***********@pc-news.cogsci.ed.ac.uk> ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <cp**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote:

Other word sizes that were popular among non-byte addressable machines ^^^^^^^are 12, 18 and 60 (for supercomputers).

And 24. The ICL 1900 series and compatibles used that. It was
typically used with a 6-bit character set, 4 to a word.

I was mentioning the popular sizes, rather than attempting an exhaustive
enumeration. Many other sizes have been used by one architecture or
another, especially during the late fifties and the early sixties.

For example, the first electronic computer used at CERN, a Ferranti
machine, had 40-bit words. Later, they got a 48-bit CDC machine.

However, 12 and 18-bit words were the most popular among the early minis
36 for "full size" computers and 60 for supercomputers. As these numbers
suggest, all these machines were designed with a 6-bit character set in
mind (usually, the BCD character set).

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

[Dan Pop]

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Dan Pop]

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

Da*****@cern.ch (Dan Pop) writes:

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

Da*****@cern.ch (Dan Pop) writes:
[...]
It's the definition of byte provided by C for those systems that you're
talking about. The redefinition of "byte" in the C standard was a gross
mistake: the standard doesn't really need it, "character" is good enough
for its purposes and the term "byte" already had a well established
meaning in computing.

In my opinion, there were two errors: the redefinition of "byte", and
the close association of bytes and characters.
My point was that "byte" was not needed at all by the C standard, since
"character" could have been used instead.

It would have been better to avoid the word "byte" altogether, use
something like "storage unit" to refer to the fundamental unit of
addressible memory, and not require a character to be one byte.

You don't need to bother at all with the fundamental unit of addressable
memory in the C standard, if all the types have sizes that are multiples ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ of char, so sizeof(char) == 1 still holds.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You're still assuming that the fundamental unit of addressable memory
has to be a character.

Nope, I don't. I'm merely assuming what I have underlined above.

If you still don't get it, consider an implementation on x86 where
the types char and short are 16-bit, int, long and float 32-bit,
double 64-bit and long double 80-bit.

On this implementation, sizeof(int) == 2 and sizeof(double) == 4 and
any pointer value with the least significant bit set is invalid.

Perfectly usable for hosted applications, maybe not so handy for
freestanding ones (e.g. OS kernels and device drivers).

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

[Dan Pop]

In <pa****************************@netactive.co.uk> Lawrence Kirby <lk****@netactive.co.uk> writes:

On Fri, 03 Dec 2004 13:36:09 +0000, Dan Pop wrote:

In <y8**********@ieee.org> Randy Yates <ya***@ieee.org> writes:

Erik Trulsson <er******@student.uu.se> writes:

Yes, they can. ISO C does not specify *the* range of integers, but it
does specify *a* *minimum* range of integers. Not quite the same thing.

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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[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]

In <pa****************************@netactive.co.uk> Lawrence Kirby <lk****@netactive.co.uk> writes:

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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Lawrence Kirby]

On Thu, 09 Dec 2004 14:25:45 +0000, Dan Pop wrote:

In <pa****************************@netactive.co.uk> Lawrence Kirby <lk****@netactive.co.uk> writes:

On Fri, 03 Dec 2004 13:36:09 +0000, Dan Pop wrote:

In <y8**********@ieee.org> Randy Yates <ya***@ieee.org> writes:

Erik Trulsson <er******@student.uu.se> writes:

> Yes, they can. ISO C does not specify *the* range of integers, but it
> does specify *a* *minimum* range of integers. Not quite the same thing.

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.
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.

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.

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.

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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^

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.

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

Lawrence

[Dan Pop]

In <pa****************************@netactive.co.uk> Lawrence Kirby <lk****@netactive.co.uk> writes:

On Thu, 09 Dec 2004 14:25:45 +0000, Dan Pop wrote:

In <pa****************************@netactive.co.uk> Lawrence Kirby <lk****@netactive.co.uk> writes:

On Fri, 03 Dec 2004 13:36:09 +0000, Dan Pop wrote:

In <y8**********@ieee.org> Randy Yates <ya***@ieee.org> writes:

>Erik Trulsson <er******@student.uu.se> writes:
>
>> Yes, they can. ISO C does not specify *the* range of integers, but it
>> does specify *a* *minimum* range of integers. Not quite the same thing.
>
>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.

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.

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.

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.

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.

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.

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.

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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Albert van der Horst]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

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 ...
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>

Groetjes Albert

--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

[Keith Thompson]

Albert van der Horst <al****@spenarnc.xs4all.nl> writes:
[...]

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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.