Does C really now that little?

[Martin Marcher]

Hi,

I've read several questions and often the answer was

'C knows nothing about [lots of different stuff here].'

So if C knows that little as some people say, what are the benefits, I
mean do other languages know more or is it a benefit that C knows nearly
nothing (what I can think about is that C is the largest common divisor
defined on most available platforms)?

This question came to my mind when I was reading "Serial Number of the
Hard Drive" (Message ID: bh************@ID-191020.news.uni-berlin.de).
Because I often read 'Unix is written in C' I'm asking myself how an OS
can be written in C if it knows nothing about anything.

And please stay on the newbiest level possible so I can understand that or
just tell me to wait 'till I learned more :)

thx
Martin
--
http://wiki.mnemonisch.net

[Thomas Matthews]

Martin Marcher wrote:

Hi,

I've read several questions and often the answer was

'C knows nothing about [lots of different stuff here].'

So if C knows that little as some people say, what are the benefits, I
mean do other languages know more or is it a benefit that C knows nearly
nothing (what I can think about is that C is the largest common divisor
defined on most available platforms)?

This question came to my mind when I was reading "Serial Number of the
Hard Drive" (Message ID: bh************@ID-191020.news.uni-berlin.de).
Because I often read 'Unix is written in C' I'm asking myself how an OS
can be written in C if it knows nothing about anything.

And please stay on the newbiest level possible so I can understand that or
just tell me to wait 'till I learned more :)

thx
Martin

The issue is that there is a finite set of functionality in the
language. Users are allowed to augment that functionality, but it
won't be discussed in this newsgroup.

The Unix operating system was written using the C language, along
with a whole bunch of platform specific code. The code that is
platform specific won't be discussed here.

There is nothing wrong with you writing a program that uses
platform extensions to read the serial number or other harddisk
information. Since the issue is not in the domain of the C language,
it won't be discussed here.

Also be aware that if the issue is not in the domain of the
standard C language, it may not exist on all platforms.

--
Thomas Matthews
Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html

[Mike Wahler]

Martin Marcher <ma*******@gmx.at> wrote in message
news:pa****************************@gmx.at...

Hi,

I've read several questions and often the answer was

'C knows nothing about [lots of different stuff here].'

So if C knows that little as some people say, what are the benefits, I
mean do other languages know more or is it a benefit that C knows nearly
nothing (what I can think about is that C is the largest common divisor
defined on most available platforms)?
I'd call it 'lowest common denominator' (in context of
'well-established' high level languages).

A major design goal of (standard) C was platform-independence.
So the committee defined a 'minimal' 'abstract machine' to
host a C program, which only contains the minimum 'components'
of a computer system (e.g. data storage, arithmetic, logic,
control flow, external data storage (via 'streams'), etc).

This allows it to include many types of systems, from e.g.
a chip embedded in an automobile engine, to desktop PCs.
Those systems that have 'additional' features (such as printers,
directory systems etc.) typically have nonstandard, machine-
specific code (written in whatever language) for them that offers
an interface with C. This code should be described in the
documentation for a specific C implementaion and/or operating
system.

This question came to my mind when I was reading "Serial Number of the
Hard Drive" (Message ID: bh************@ID-191020.news.uni-berlin.de).
Because I often read 'Unix is written in C' I'm asking myself how an OS
can be written in C if it knows nothing about anything.
Unix cannot fully be implemented using only standard C.
Machine-specific knowledge is needed. Also note that
when Unix was created, C had not yet been standardized.
And please stay on the newbiest level possible so I can understand that or
just tell me to wait 'till I learned more :)

I hope my explanation helped.

-Mike

[Lew Pitcher]

Martin Marcher wrote:

Hi,

I've read several questions and often the answer was

'C knows nothing about [lots of different stuff here].'

So if C knows that little as some people say, what are the benefits, I
mean do other languages know more or is it a benefit that C knows nearly
nothing (what I can think about is that C is the largest common divisor
defined on most available platforms)?

This question came to my mind when I was reading "Serial Number of the
Hard Drive" (Message ID: bh************@ID-191020.news.uni-berlin.de).
Because I often read 'Unix is written in C' I'm asking myself how an OS
can be written in C if it knows nothing about anything.

And please stay on the newbiest level possible so I can understand that or
just tell me to wait 'till I learned more :)

There's C and there's /C/.

Standard C (the topic of discussion here in comp.lang.c) is defined such
that it offers the same facilities no matter where it is used. These minimum
facilities are enough to build fairly comprehensive applications, although
not necessarily operating systems or device drivers.

However, with a little additional "glue" (in the form of external add-on
libraries), you can extend C such that it /can/ be used to write operating
systems and device drivers. For operating systems, the glue commonly
consists of a handfull of Assembly language modules that provide a
consistant interface to the hardware. For device drivers, the "glue"
consists of libraries or modules that provide a consistant interface to the
operating system.

In theory, with the proper hardware, it should be possible to write an
operating system with Standard C. In practice, it's not as simple as all that.

In comp.lang.c, we discuss the C as in "Standard C" that can be used to
create applications that are platform-independant. The other C, the C that
requires platform-specific extensions, is left to other groups to discuss.
--

Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

[Dan Pop]

In <pa****************************@gmx.at> Martin Marcher <ma*******@gmx.at> writes:

I've read several questions and often the answer was

'C knows nothing about [lots of different stuff here].'
Which should be read as: ``the C language specification doesn't mention
anything about [lots of different stuff here]''.
So if C knows that little as some people say, what are the benefits, I
mean do other languages know more or is it a benefit that C knows nearly
nothing (what I can think about is that C is the largest common divisor
defined on most available platforms)?
If you can restrict your code to what the C "knows about", it will be
usable on any platform with a C compiler. It is true that other languages
know more, but it is equally true that they cannot be implemented on as
many platforms as C (at least, without a significant loss of efficiency).

Another reason C knows so little is that the people who wrote the language
specification didn't bother to put more into it. As a result, even
things that could be efficiently implemented practically everywhere are
missing from the language specification, the usual excuse being that
they've been left for other standards to define. But those other
standards are not as widely implemented as the C standard, so plenty of
things that are needed on practically every platform need to be coded in
a platform-specific way.
This question came to my mind when I was reading "Serial Number of the
Hard Drive" (Message ID: bh************@ID-191020.news.uni-berlin.de).
Because I often read 'Unix is written in C' I'm asking myself how an OS
can be written in C if it knows nothing about anything.
Nobody has implemented any OS using only the features of C fully specified
by the language specification. As a result, there is no OS that can be
used on *any* platform with a C implementation.

OTOH, C programming is not limited to the features fully specified by the
language specification. Each implementation completes certains parts that
are only partly specified by the language definition (the implementation
defined features) and also adds its own extensions to the language
(and library) specification. People who write OSs in C make heavy use
of these extra features. But even with these extra features, certain
(usually small) parts of the OS still have to be written in assembly.

As a concrete example, C knows nothing about directories. Yet, it is
perfectly possible to write a C program that lists the contents of a
directory on any platform supporting the concept of directory (i.e.
practically on any hosted platform).
And please stay on the newbiest level possible so I can understand that or
just tell me to wait 'till I learned more :)

The thing you need to understand is that this newsgroup decided to focus
only on the parts of C that are specified by the language definition,
leaving the discussion about platform-specific extensions to
platform-specific newsgroups.

The big advantage of this approach, from the newbie's point of view
is that, by reading the newsgroup, he gets a clear idea about what
is a standard C feature and what is an extension. This helps a lot
when having to write portable C code (even if parts of the application
will have to be written in non-portable C).

The advantage for the more experienced programmer is that, by reading
this newsgroup and the newsgroup dedicated to programming on his platform,
he doesn't have to waste any time with questions and answers about C
programming on other platforms, about which he couldn't care less.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Martin Marcher]

On Tue, 12 Aug 2003 16:43:16 +0000, Thomas Matthews wrote:

The issue is that there is a finite set of functionality in the language.
My question was more like, why it is that C knows so little (since you
didn't answer me I allow myself to asume that C really knows very little).
Users are allowed to augment that functionality, but it won't be discussed
in this newsgroup.
Problem 1: The only one that can forbid or allow me aksing questions is my
mother

Problem 2: If you would be so kind to point me to a group where I can ask
that question (I didn't find a group called
comp.lang.c.historical-background or similiar)

Problem 3: Please tell me the reason why asking this question is OT in
this group, maybe the question came thru the wrong way but to me it
sounded much like a question about ANSI C, tough it is more general than
why this or that code doesn't react like expected.
The Unix operating system was written using the C language, along with a
You repeat what I said.
whole bunch of platform specific code. The code that is platform specific
won't be discussed here.
I didn't ask anything about that code.
There is nothing wrong with you writing a program that uses platform
extensions to read the serial number or other harddisk information. Since
the issue is not in the domain of the C language, it won't be discussed
here.

If you would have had a look at the post I mention in my original post you
would have seen that I didn't ask the question, so you don't need to tell
me not to discuss platform specific code, I'm really new to C and did my
best to stay standard conform, also if you search my previous posts I
mentioned everytime I wasn't sure wether it was ANSI C or not, so people
that strictly refer to ANSI C aren't forced to read further. A simple 'ask
at this group' would be enough

greets
Martin

PS: in case you want to flame use my mail address because flames are
off-topic and users are not allowed to do this in the newsgroup
--
http://wiki.mnemonisch.net

[Martin Marcher]

Hi,

I think the 'abstract machine' Mike Wahler mentioned was the missing link
in my brain to get the point of it. I thought that it was just some 'per
definition we say that it is this way'-stuff, but couldn't think of what
kind of definition the people defining the standard were thinking about,
especially since I never thought that access to directories could be
outside of the standard, which makes the mentioned 'abstract machine'
really minimal

thx all
Martin
--
http://wiki.mnemonisch.net

[Eric Sosman]

Mike Wahler wrote:

I'd call it 'lowest common denominator' (in context of
'well-established' high level languages).

Topic drift: Why do people so often say "lowest (or
least) common denominator" when they mean "greatest common
denominator?"

ObOnTopicCodeSample:

/* least_common_denominator() calculates and returns
* the least common denominator of two unsigned integers,
* using an algorithm attributed to A.E. Neumann.
*/
unsigned int least_common_denominator(
unsigned int u, unsigned int v)
{
return 1;
}

--
Er*********@sun.com

[Default User]

Martin Marcher wrote:

Problem 1: The only one that can forbid or allow me aksing questions is my
mother

Turns out you're wrong about that.

*plonk*


Brian Rodenborn

[Arthur J. O'Dwyer]

On Tue, 12 Aug 2003, Martin Marcher wrote:

On Tue, 12 Aug 2003 16:43:16 +0000, Thomas Matthews wrote:

The issue is that there is a finite set of functionality in the language.
My question was more like, why it is that C knows so little (since you
didn't answer me I allow myself to asume that C really knows very little).

Or that C doesn't specify lots of things [OS stuff, sound, graphics,
.... basically anything having to do with time and space instead of
algorithms].

Users are allowed to augment that functionality, but it won't be discussed
in this newsgroup.

Problem 1: The only one that can forbid or allow me aksing questions is my
mother

Hey, now. Thomas didn't say your question was OT; he said that while
users are allowed to augment C's functionality, we don't discuss that
here. IOW, it's fine to ask what C does and doesn't have. It's just
not okay to ask specifically *about* things that C doesn't have.
Like, don't ask, "How do I make pictures in C?" or "How do I tell if
the Shift key is being pressed?" because those aren't things that C
can do [portably].
Problem 2: If you would be so kind to point me to a group where I can ask
that question (I didn't find a group called
comp.lang.c.historical-background or similiar)
Here is fine.
Problem 3: Please tell me the reason why asking this question is OT in
this group, maybe the question came thru the wrong way but to me it
sounded much like a question about ANSI C, [though] it is more general
than why this or that code doesn't react like expected.

Your question was on-topic. And the answer to your question is,
"Yes, C doesn't know much. And the stuff that C doesn't know is
off-topic."

The Unix operating system was written using the C language, along
with a

You repeat what I said.

whole bunch of platform specific code. The code that is platform specific
won't be discussed here.

I didn't ask anything about that code.

Then it is not the case that your question won't be discussed here.

There is nothing wrong with you writing a program that uses platform
extensions to read the serial number or other harddisk information. Since
the issue is not in the domain of the C language, it won't be discussed
here.

If you would have had a look at the post I mention in my original post you
would have seen that I didn't ask the question, so you don't need to tell
me not to discuss platform specific code,

Heck, if you already *knew* not to discuss platform-specific code,
then wouldn't you have read the FAQ, or even a couple pages of the
Standard, already? Then you wouldn't have needed to ask the question
you *did* ask. [Not trying to be harsh; just pointing out the
obvious - people who don't know much about C and post here usually
need the reminder that execl() or RunWindows() aren't standard C.]

HTH,
-Arthur

[Arthur J. O'Dwyer]

On Tue, 12 Aug 2003, Eric Sosman wrote:

Mike Wahler wrote:

I'd call it 'lowest common denominator' (in context of
'well-established' high level languages).

Topic drift: Why do people so often say "lowest (or
least) common denominator" when they mean "greatest common
denominator?"

Bzzt. You mean "greatest common divisor," a la Euclid.
The "lowest common denominator" phrase refers to fractions,
where the LCD of 3/7 and 2/3 is 21, for example.

"Lowest common denominator," involving as it does the
words "low" and "common," is much more popular as a
pejorative, at least on this side of the pond - e.g.,
"Temptation Island" is a TV show appealing to the "lowest
common denominator" in TV audiences.

Saying C is the "greatest common divisor" among languages
just sounds weird to me. ;-)

-Arthur

[Larry Doolittle]

In article <CZ***************@news20.bellglobal.com>, Lew Pitcher wrote:

However, with a little additional "glue" (in the form of external add-on
libraries), you can extend C such that it /can/ be used to write operating
systems and device drivers. For operating systems, the glue commonly
consists of a handfull of Assembly language modules that provide a
consistant interface to the hardware.
Without distracting from the conceptual message, let me
modify a detail. On many computers, much interesting
interaction with the hardware happens by reading and writing
special memory locations. C gives a perfectly clean syntax
for that, using volatile <type>* pointers.

So for instance, an operating system that needed to know if some
hypothetical Ethernet chip had received any new packets could

int packet_cnt;
volatile int *packet_cnt_reg = (volatile int *)0xe7000010;
if ((packet_cnt = *packet_cnt_reg) != 0) {
/* receive a packet */
}

No assembly required. ;-)
And indeed, OS writers use this technique whenever possible, for the
obvious readability and portability-across-architectures advantages
over assembly.
In theory, with the proper hardware, it should be possible to write an
operating system with Standard C.

Maybe the above concept is what you were referring to.
But when people bring it up on comp.lang.c, they are
chased away because such "wild" pointer dereferencing
triggers "undefined behavior".

- Larry

[Richard Heathfield]

Eric Sosman wrote:

<snip>

ObOnTopicCodeSample:

/* least_common_denominator() calculates and returns
* the least common denominator of two unsigned integers,
* using an algorithm attributed to A.E. Neumann.
*/
unsigned int least_common_denominator(
unsigned int u, unsigned int v)
{
return 1;
}

I disagree that 1 is the least common denominator. It's extremely common.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Scott McPhillips]

Martin Marcher wrote:

especially since I never thought that access to directories could be
outside of the standard, which makes the mentioned 'abstract machine'
really minimal

Then your awareness of the application domain is sharply limited.
Millions of machines that do not have disks or disk directories have
been programmed in C. For example: microwave ovens, hotel room locks,
cell phones, ...

--
Scott McPhillips [VC++ MVP]

[Richard Heathfield]

Martin Marcher wrote:

Hi,

I've read several questions and often the answer was

'C knows nothing about [lots of different stuff here].'
This is a "cutesy" way of saying "to do <foo> requires
implementation-specific extensions which are not available on all
implementation and, even on those implementation where they are available,
the way in which those extensions are used is very likely to differ from
one implementation to another".

So if C knows that little as some people say, what are the benefits,
Portability /and/ power. If you modularise your code so that all the
portable code is separate from the non-portable code, you can move the code
from one implementation to another with a minimum of effort, because you
only have to re-write the non-portable bit. On one project I worked on - a
browser for embedded systems - a mere 1% of 500,000 lines of code was
non-portable. To move to a new platform (which this company did on a
regular basis), the team needed only to rewrite 5,000 lines of code, all of
which were isolated into a few core modules for easy identification.
I
mean do other languages know more or is it a benefit that C knows nearly
nothing (what I can think about is that C is the largest common divisor
defined on most available platforms)?

Languages that are only implemented on one platform can take that platform's
features for granted. Those that are not, can't. That doesn't mean you lose
any power, though, because you can use an implementation's extensions to
gain access to that platform's features. If you do this thoughtfully and
carefully, the portability cost can be very low indeed.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Delorme]

Scott McPhillips a écrit :

Then your awareness of the application domain is sharply limited.
Millions of machines that do not have disks or disk directories have
been programmed in C. For example: microwave ovens, hotel room locks,
cell phones, ...

This is not a problem of having discs or not. C supports files through
functions like rename(), remove(),... Then, why are directories, which are
useful at keeping files well ordered, not part of the language?
Why that feature is in, and why this one is out? Why complex numbers are
supported in C99? How many applications need complex numbers? And why not
matrix algebra then? The C language already supports two level of
compliance for freestanding or hosted environment. Why not adding another
level, called "graphical environment", with graphical functions added into
the standard libraries?
I don't think there is any rationale here. It probably just depends on the
people attending the commitee meetings and their particular needs.

--
Richard

[Kevin Easton]

Ben Pfaff <bl*@cs.stanford.edu> wrote:

Eric Sosman <Er*********@sun.com> writes:

Mike Wahler wrote:

>
> I'd call it 'lowest common denominator' (in context of
> 'well-established' high level languages).

Topic drift: Why do people so often say "lowest (or
least) common denominator" when they mean "greatest common
denominator?"

Because they do mean least common denominator. If I am adding
1/3 to 1/2, then the LCD is 6: 1/3 + 1/2 = 5/6. I could also use
any integer multiple of 6. There is no greatest common
denominator, because I can always choose a larger one.

The LCD is also known as the LCM (least common multiple).

Perhaps you are thinking of the greatest common factor? The
greatest common factor is the largest integer that evenly divides
all of a set of integers.

A.K.A the Greatest Common Divisor, or GCD, which is perhaps where the
confusion arises from? ("denominator" / "divisor").

- Kevin.

[Chris Torek]

In article <3f**********************@news.club-internet.fr>
Richard Delorme <ab****@nospam.fr> writes, in part:

This is not a problem of having discs or not. C supports files through
functions like rename(), remove(),... Then, why are directories, which are
useful at keeping files well ordered, not part of the language? ... I don't think there is any rationale here. It probably just depends on the
people attending the commitee meetings and their particular needs.

It is certainly true that C is a creation of humans, and humans
are rarely consistent or logical. Thus, we should not expect C to
be all that consistent and logical. :-) (Nonetheless, many people
*do* seem to expect it, perhaps because C is "pretty consistent
and logical", at least when compared to so many other languages.)

In this particular case, however, I think we should observe that
the original C standardization effort included folks from the
mainframe world, where people use operating systems like Univac's
EXEC-8 and IBM's MVS and TSS.

One of the interesting aspects of these OSes is that they do not
*have* directories. They *do* have files, and file names may appear
in "file catalogues", which are very much *like* directories; or
perhaps in "data sets" or "partitions" or other directory-like
concepts. But if one sits down with a set of "directory operations"
-- "what would we like to be able to do with a directory facility
in a C-like language" -- and tries to apply it to these systems,
it comes up short every time.

Interestingly, however, if one does this with ordinary files, it
likewise comes up short. These mainframes have more file types
than you can shake a Microsoft Product at, and portable C cannot
deal with those either. So why are any files at all available in
C, yet directories are not?

Of course, only those who were on the X3J11 (ANSI C) committee in
the 1980s could really answer this, but we have some very strong
hints available in the C89 Rationale, and in the charter that the
X3J11 committee had in the first place: to standardize existing
practice, without inventing new practice. K&R C's <stdio.h> and
associated functions were in fact in use on these mainframes; stdin
and stdout worked, and fopen()ing files gave some minimal functionality.
But K&R C had no standard directory operations: there was no
<dir.h> or <dirent.h>, no opendir() function, no scandir(); indeed,
all of the various functions that are rather common today were rare
at the time. In short, there was no existing practice to standardize.

(Not that this stopped the X3J11 folks in all cases. For instance,
they stole "const" from C++, and broke it. :-) They also picked
the wrong rules for dealing with narrow unsigned arithmetic, where
the Unix compilers got it right but one particular PC compiler used
the silly "value-preserving" rules. They even tried to add an
11th-hour unworkable version of C99's "restrict", called "noalias".
But for whatever reason, they did not invent directory operations.)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[Jeff]

"Larry Doolittle" <ld******@recycle.lbl.gov> wrote in message
news:slrnbjijan.b92.ld******@recycle.lbl.gov...

In article <CZ***************@news20.bellglobal.com>, Lew Pitcher wrote:

However, with a little additional "glue" (in the form of external add-on
libraries), you can extend C such that it /can/ be used to write operating systems and device drivers. For operating systems, the glue commonly
consists of a handfull of Assembly language modules that provide a
consistant interface to the hardware.
Without distracting from the conceptual message, let me
modify a detail. On many computers, much interesting
interaction with the hardware happens by reading and writing
special memory locations. C gives a perfectly clean syntax
for that, using volatile <type>* pointers.

So for instance, an operating system that needed to know if some
hypothetical Ethernet chip had received any new packets could

int packet_cnt;
volatile int *packet_cnt_reg = (volatile int *)0xe7000010;
if ((packet_cnt = *packet_cnt_reg) != 0) {
/* receive a packet */
}

No assembly required. ;-)
And indeed, OS writers use this technique whenever possible, for the
obvious readability and portability-across-architectures advantages
over assembly.

In theory, with the proper hardware, it should be possible to write an
operating system with Standard C.

I don't agree. Some feature can be only implemented in assembly. How can we
access the system register CR0 by C language ?

Maybe the above concept is what you were referring to.
But when people bring it up on comp.lang.c, they are
chased away because such "wild" pointer dereferencing
triggers "undefined behavior".

- Larry

--
Jeff

[ArWeGod]

"Martin Marcher" <ma*******@gmx.at> wrote in message
news:pa****************************@gmx.at...

Hi,

I've read several questions and often the answer was

'C knows nothing about [lots of different stuff here].'

So if C knows that little as some people say, what are the benefits, I
mean do other languages know more or is it a benefit that C knows nearly
nothing (what I can think about is that C is the largest common divisor
defined on most available platforms)?

The command set for C is small and elegant. In the "bad old days" there were
languages that were so complex that one couldn't keep the entire language in
one's mind. Ada comes to mind as an example. It was impossible to become a
true expert. By keeping the command set to a consistant, small size allows
one to truly master the language.

As to how it can do so much with so little, well C can be expanded with
external libraries. These can be written in Assembler, C, or another
language. So, even though C has no built-in input/output functions, the
standard library STDIO.H declares several functions, like fread() and
printf(), which allow programs to do input and output. The particular
version of these routines (the implementation)will have to be non-portable,
Operating System (OS) based code. So, Microsoft writes a printf() that works
on DOS machines, and I link it into my program, and I can output "Hello,
world!" to my computer screen. When I move the program to a Linux box, I
recompile with gcc and it will build my executable with a Linux-based
printf() that still outputs "Hello, world!" to my computer screen. Same
source code, two differnt executables that can only run on their own OS.

Unfortunately, with C++, we've taken a step back into the "bigger = better"
style of language creation. However, as PDA's and phones begin to need
programming, you can bet that C will be there first. There will be a big
need to avoid platform specific programming, as new device come out
constantly and your code will have to work right, right now.

Ar*****@sbcglobal.net

[Chris Torek]

>"Larry Doolittle" <ld******@recycle.lbl.gov> wrote in message

news:slrnbjijan.b92.ld******@recycle.lbl.gov...

So for instance, an operating system that needed to know if some
hypothetical Ethernet chip had received any new packets could

int packet_cnt;
volatile int *packet_cnt_reg = (volatile int *)0xe7000010;
if ((packet_cnt = *packet_cnt_reg) != 0) {
/* receive a packet */
}

No assembly required. ;-)
And indeed, OS writers use this technique whenever possible, for the
obvious readability and portability-across-architectures advantages
over assembly.
True -- but such portability can be overestimated. For instance,
the Lance Ethernet chip has two 16-bit registers (the "RAP" and
"RDP", or Register Address Port and Register Data Port) -- so we
(read "I") wrote a driver using the following data structure
(actually this predated C99 uint16_t; I used plain old unsigned
short):

struct lereg1 {
uint16_t ler1_rdp;
uint16_t ler1_rap;
};

Now, you might think a "volatile struct lereg1 *" variable would
suffice to access these on any machine on which the hardware can
be plugged in -- but you would be wrong.

On the MIPS as used in the DECstation, for instance, the data
structure above is wrong. It needs to read:

struct lereg1 {
uint16_t ler1_rdp;
uint16_t ler1_pad1;
uint16_t ler1_rap;
uint16_t ler1_pad2; /* optional */
};

The reason is that the CPU always does 32-bit transactions on the
bus, so in order to make sure that I/O to the RDP does not also
read or write the RAP (and vice versa), the hardware is physically
wired up with Lance address line A1 connected to bus address line
A2.

Now, one might dismiss this as a special case ... but then there
are architectures in which accesses to "memory" that does not
actually work like RAM must be preceded and/or followed by specal
I/O-barrier instructions. These instructions should (perhaps
even "must") *not* be used for accesses to shared-memory variables,
however, which would also be labeled "volatile", hence the compiler
should not automatically insert them. Instead, C code that reads
or writes the RAP and RDP needs explicit barrier instructions as
well.

In short, while abstracting the details is a good idea, it only
takes you partway. Using "volatile" and other such tricks is
necessary, but may not be sufficient. As an OS writer, I just code
what I know is needed now and try to leave enough room for later
"improvements". :-)

Then, in article <bh**********@news.hgc.com.hk>, Jeff <no*****@notexist.com>
adds:

I don't agree. Some feature can be only implemented in assembly. How can we
access the system register CR0 by C language ?

Indeed, some architectures make it impossible to do anything
"not memory-like" using "memory-like" accesses. For instance,
instead of reading the RAP and RDP with "volatile struct lereg1 *"
pointers, we might have to do something like:

io_port_write(LANCE_RAP, 1); /* point to register 1 */
result = io_port_read(LANCE_RDP); /* read register 1 */
/* replaces: reg->ler1_rap = 1; result = reg->ler1_rdp; */

On the Intel x86 in particular, one may need to use the "inw" and
"outw" instructions here.

Some (many?) C compilers offer some sort of "escape to assembler"
feature so that one can write inw() and outw() without having to
use actual subroutine calls (a waste of both code space and CPU
time, on the x86). These features are not only hardware-dependent,
they are compiler-dependent as well. GCC's "__asm__ volatile"
syntax does not work in Microsoft C compilers. (You need the
"volatile" as well as the __asm__ keyword to prevent GCC from moving
and combining the instruction when it has indescribable side
effects.)

What this all boils down to, though, is what I think Lew Pitcher
was getting at here:
In article <CZ***************@news20.bellglobal.com> Lew Pitcher wrote:

In theory, with the proper hardware, it should be possible to write an
operating system with Standard C.

which can be rephrased as: "If -- and only if -- the hardware is
*extremely* cooperative (and hardware never is), one could write
an entire OS without ever stepping outside the bounds of C syntax
and with only `slightly dubious' semantics, such as assuming that
particular hardware devices are at particular numeric addresses,
and that casting integer constants to the right pointer types allows
you to access them this way." The source code would not be portable,
and even changing the compiler could cause it to fail (if, e.g.,
the new compiler does not have the same semantics for
integer-to-"pointer-to-hardware-device" conversions).

Since the hardware *never* cooperates to this extent, and since
the constructs needed for working around the balky hardware are
themselves not portable, operating systems are never written in
nothing but Standard C. At best, the majority of the OS code
is Standard C, so that only a small minority of code needs to be
rewritten for each port (to new hardware and/or new compilers).
(Performance factors often get in the way here too -- more code
is machine- and compiler-dependent than strictly necessary, in
these OSes, because the result is a system that runs 30% faster.)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[Jack Klein]

On 12 Aug 2003 18:05:33 -0600, Chris Torek <no****@elf.eng.bsdi.com>
wrote in comp.lang.c:

[big snip]

(Not that this stopped the X3J11 folks in all cases. For instance,
they stole "const" from C++, and broke it. :-) They also picked
I strongly disagree with your first statement above. They stole
"const" from C++ and FIXED it. They also didn't break "volatile", as
C++ has quite badly, albeit inadvertently. A very large percentage of
production C programming today is in the realm of embedded systems,
and the C semantics of const are ideal for read-only objects in
ROM/EPROM/Flash etc.
the wrong rules for dealing with narrow unsigned arithmetic, where
the Unix compilers got it right but one particular PC compiler used
the silly "value-preserving" rules. They even tried to add an
On the other hand, your second gripe is right on. "Value preserving"
is at the top of my list of things that went wrong in 1989.
11th-hour unworkable version of C99's "restrict", called "noalias".
But for whatever reason, they did not invent directory operations.)

You forgot to mention that enums are so crippled as to be almost
useless in both C and C++, and bit-fields likewise, and...

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Chris Torek]

In article <5n********************************@4ax.com>
Jack Klein <ja*******@spamcop.net> writes:

I strongly disagree with your first statement above. They stole
"const" from C++ and FIXED it. ...
the C semantics of const are ideal for read-only objects in
ROM/EPROM/Flash etc.

If we want const to mean "read-only object as stored in ROM or
equivalent", const should be a storage-class, not a type-qualifier.

The part of C that is particularly broken with respect to "const"
has to do with pointers that point to "const char *", when using
const as a type-qualifier. For instance, suppose you have a
function f() that takes a pointer to "const char *" and applies
strlen to the various p[i] values:

void f(const char **p) {
... strlen(p[i]) ...
}

but never modifies p, p[i], or p[i][j].

Now we have a function much like main(), in which we have a
"char **argv", reasonably suited to pass to f():

f(argv);

but C's type rules prohibit this. (C++'s type rules allow it
if we change f() to take "const char *const *", but even then,
C's type rules prohibit it.)

If "const" were a storage-class specifier, the call would be OK
(and any "const" keywords in f()'s parameter would effectively be
a no-op, or prohibited entirely).
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[Daniel Haude]

On Tue, 12 Aug 2003 19:18:56 +0200,
Martin Marcher <ma*******@gmx.at> wrote
in Msg. <pa****************************@gmx.at>

Users are allowed to augment that functionality, but it won't be discussed
in this newsgroup.
Problem 1: The only one that can forbid or allow me aksing questions is my
mother

Uh-oh...
Problem 2: If you would be so kind to point me to a group where I can ask
that question (I didn't find a group called
comp.lang.c.historical-background or similiar)
comp.lang.c is the perfectly correct place to ask the question why C has
or has not certain features.
Problem 3: Please tell me the reason why asking this question is OT in
this group,
Nobody accused you of off-topicality, because...
If you would have had a look at the post I mention in my original post you
would have seen that I didn't ask the question,
What several people pointed out to you is that this group isn't concerned
with platform-specific stuff, using reading information from a hard disk
as an example. Nobody accused you of barging in here asking
platform-specific stuff (as happens several times a day).
so you don't need to tell
me not to discuss platform specific code, I'm really new to C and did my
best to stay standard conform, also if you search my previous posts I
mentioned everytime I wasn't sure wether it was ANSI C or not, so people
that strictly refer to ANSI C aren't forced to read further. A simple 'ask at this group' would be enough
Why do you fail to understand that YOU asked YOUR question at the CORRECT
newsgroup and NOBODY said otherwise?
PS: in case you want to flame use my mail address because flames are
off-topic and users are not allowed to do this in the newsgroup

And this comes from Mr "The only one that can forbid or allow me aksing
questions is my mother"?

For I minute I thought, wow, here comes a role-model thread: A newbie
comes in and asks a question, modestly and politely, and already a couple
of our highly regarded specialist regulars (to avoid the term "guru") give
him equally (and unusually) polite, verbous answers. Sadly, Mr. newbie
reads into those answers criticism, even flaming, snd heads off down the
well-trodden path into the killfiles by educating people about c.l.c
topicality.

--Daniel

--
"With me is nothing wrong! And with you?" (from r.a.m.p)

[Nils Petter Vaskinn]

On Wed, 13 Aug 2003 11:06:32 +0000, Dan Pop wrote:

In <3F***************@mvps.org> Scott McPhillips <sc******@mvps.org>
writes:

Martin Marcher wrote:

especially since I never thought that access to directories could be
outside of the standard, which makes the mentioned 'abstract machine'
really minimal

Then your awareness of the application domain is sharply limited.
Millions of machines that do not have disks or disk directories have
been programmed in C. For example: microwave ovens, hotel room locks,
cell phones, ...

Bogus argument: we're not talking about freestanding implementations,
which need not provide any of the standard library functions, anyway.
Therefore, including directory support into the standard C library would
not affect freestanding implementations in any way. Furthermore, it
wouldn't affect hosted implementations with no directory support either:
opendir (or whatever) could simply fail.

But for C to know about filesystems you would have to define functions to
access that filesystem. While this may seem a good idea now, future
advances in filesystems (or how OS'es deal with them) may make that
interface a bad choice. But if the filesystem interface is part of the
language making a change to it is hard, (as opposed to linking new
programs against the new library on old programs against the old one).

If C knows nothing about filesystems you are free to choose a library with
an interface that suits YOU and/or your selected plattform to access
filesystems. If on the other hand C pretended to know the ultimate
filesystem interface you would effectively have no choice, since alternate
ways would dwindle away into obscurity.
regards
NPV

[Kevin Easton]

Chris Torek <no****@elf.eng.bsdi.com> wrote:

In article <5n********************************@4ax.com>
Jack Klein <ja*******@spamcop.net> writes:

I strongly disagree with your first statement above. They stole
"const" from C++ and FIXED it. ...
the C semantics of const are ideal for read-only objects in
ROM/EPROM/Flash etc.
If we want const to mean "read-only object as stored in ROM or
equivalent", const should be a storage-class, not a type-qualifier.

The part of C that is particularly broken with respect to "const"
has to do with pointers that point to "const char *", when using
const as a type-qualifier. For instance, suppose you have a
function f() that takes a pointer to "const char *" and applies
strlen to the various p[i] values:

void f(const char **p) {
... strlen(p[i]) ...
}

but never modifies p, p[i], or p[i][j].

Now we have a function much like main(), in which we have a
"char **argv", reasonably suited to pass to f():

f(argv);

but C's type rules prohibit this.

For good reason. If char ** were assignment-compatible with const char
**, then you could accidentally escape const:

const char c;
char *p;
const char **q = &p; /* This is what C doesn't allow */
*q = &c; /* this looks ok, both are const.. */
*p = '!'; /* ...oh no, we just broke const on ` c ' */
(C++'s type rules allow it
if we change f() to take "const char *const *", but even then,
C's type rules prohibit it.)
I'm not sure how C++'s type rules work - does the destination have to be
const-qualified from the deepest indirection level of the type being
assigned, all the way up to the second last level?
If "const" were a storage-class specifier, the call would be OK
(and any "const" keywords in f()'s parameter would effectively be
a no-op, or prohibited entirely).

That would have the very big problem of preventing the compiler from
diagnosing modifications to const objects made through pointers:

const int a;
int *p_a = &a;

a = 10; /* Diagnostic */
*p_a = 10; /* No diagnostic */

- Kevin.

[Dan Pop]

In <pa***************************@spam.for.me.invalid > "Nils Petter Vaskinn" <[e-mail]> writes:

On Wed, 13 Aug 2003 11:06:32 +0000, Dan Pop wrote:

In <3F***************@mvps.org> Scott McPhillips <sc******@mvps.org>
writes:

Martin Marcher wrote:
especially since I never thought that access to directories could be
outside of the standard, which makes the mentioned 'abstract machine'
really minimal

Then your awareness of the application domain is sharply limited.
Millions of machines that do not have disks or disk directories have
been programmed in C. For example: microwave ovens, hotel room locks,
cell phones, ...
Bogus argument: we're not talking about freestanding implementations,
which need not provide any of the standard library functions, anyway.
Therefore, including directory support into the standard C library would
not affect freestanding implementations in any way. Furthermore, it
wouldn't affect hosted implementations with no directory support either:
opendir (or whatever) could simply fail.

But for C to know about filesystems you would have to define functions to
access that filesystem. While this may seem a good idea now, future
advances in filesystems (or how OS'es deal with them) may make that
interface a bad choice.

If well designed and generic enough, this is not going to happen. See
below.
But if the filesystem interface is part of the
language making a change to it is hard, (as opposed to linking new
programs against the new library on old programs against the old one).

If C knows nothing about filesystems you are free to choose a library with
an interface that suits YOU and/or your selected plattform to access
filesystems. If on the other hand C pretended to know the ultimate
filesystem interface you would effectively have no choice, since alternate
ways would dwindle away into obscurity.

You're missing the point. C should provide a minimal interface to
accessing directories plus a minimal interface to the information
associated with each directory entry (a minimal <dirent.h> and a minimal
<stat.h>). Each implementation can either extend these minimal interfaces
or provide alternative solutions that provide as much information as
available on the underlying OS. The minimal and possibly suboptimal C
solution doesn't prevent better solutions that are platform specific.

E.g. the existence of <stdio.h> doesn't prevent any implementation from
providing alternate I/O interfaces, more flexible and more functional than
the standard C one.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Eric Sosman]

Dan Pop wrote:

In <pa***************************@spam.for.me.invalid > "Nils Petter Vaskinn" <[e-mail]> writes:

But for C to know about filesystems you would have to define functions to
access that filesystem. While this may seem a good idea now, future
advances in filesystems (or how OS'es deal with them) may make that
interface a bad choice.
If well designed and generic enough, this is not going to happen. [...]

The design is the hard part. The most ambitious attempt
at such an abstraction layer that I've come across is that of
Common LISP, and (personal opinion) it isn't all that useful.
Smarter people than I put some serious skull sweat into the
CL scheme and came up with something inadequate; that suggests
to me that the problem is considerably nastier than it might
appear on first examination.
You're missing the point. C should provide a minimal interface to
accessing directories plus a minimal interface to the information
associated with each directory entry (a minimal <dirent.h> and a minimal
<stat.h>). Each implementation can either extend these minimal interfaces
or provide alternative solutions that provide as much information as
available on the underlying OS. The minimal and possibly suboptimal C
solution doesn't prevent better solutions that are platform specific.

E.g. the existence of <stdio.h> doesn't prevent any implementation from
providing alternate I/O interfaces, more flexible and more functional than
the standard C one.

I'm not sure how this differs from the situation that prevails
today: C offers a "minimal" directory interface (to wit, a null
directory interface), and platforms extend it in various ways.
A less vacuous (is "less vacuous" a linguistic abomination?)
interface would presumably aspire to provide a portable means of
getting at some common subset of all the file-cataloging schemes,
but the big question would be whether that subset could be large
enough to be useful. The Common LISP experience suggests that a
portable interface might be close to impotent, and that a useful
interface might not be very portable.

--
Er*********@sun.com

[Mark McIntyre]

On Tue, 12 Aug 2003 19:18:56 +0200, in comp.lang.c , Martin Marcher
<ma*******@gmx.at> wrote:

On Tue, 12 Aug 2003 16:43:16 +0000, Thomas Matthews wrote:

The issue is that there is a finite set of functionality in the language.
My question was more like, why it is that C knows so little (since you
didn't answer me I allow myself to asume that C really knows very little).

ISO C is designed to be maximally portable to different hardware and
OSes. Therefore it is a subset of what any given platform can do.
Platform specific extensions are then developed to augment C's basic
functions. However they're not topical here.

Users are allowed to augment that functionality, but it won't be discussed
in this newsgroup.

Problem 1: The only one that can forbid or allow me aksing questions is my
mother

<pedantic>
Actually you can also be forbidden from asking questions by a wide
range of other people, from the police to a maniac with a pair of
pliers and a penchant for roast tongue.
</pedantic>

The point is, this group is for discussion of ISO C. If you ask
nontopical questions here, expect to get told to ask elsewhere, then
flamed, then insulted and finally plonked.
Problem 2: If you would be so kind to point me to a group where I can ask
that question (I didn't find a group called
comp.lang.c.historical-background or similiar)
a group that specialises in the platform you want to use. Suchg
extensions are typically platform specific.
Problem 3: Please tell me the reason why asking this question is OT in
this group,

see above.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mark McIntyre]

On Wed, 13 Aug 2003 00:41:59 +0200, in comp.lang.c , Richard Delorme
<ab****@nospam.fr> wrote:

Scott McPhillips a écrit :

Then your awareness of the application domain is sharply limited.
Millions of machines that do not have disks or disk directories have
been programmed in C. For example: microwave ovens, hotel room locks,
cell phones, ...

This is not a problem of having discs or not. C supports files through
functions like rename(), remove(),... Then, why are directories, which are
useful at keeping files well ordered, not part of the language?

C supplies functions to remove things called "files" but it has no
actual idea what these things are. They could include directories,
which are after all a feature from VMS, but not say PalmOS. C
therefore cleverly allows these things to exist, to allows each
platform to support them in its own way.
Why that feature is in, and why this one is out?
Because a committee voted on whether they thought it was generically
useful or not.
Why not adding another
level, called "graphical environment", with graphical functions added into
the standard libraries?
Because the vast majority of devices on which C programs might be used
do not have any "graphical device". Therefore its not generically
useful. You're thinking too narrow.
I don't think there is any rationale here. It probably just depends on the
people attending the commitee meetings and their particular needs.

Of course, thats called "democracy in action". If you think the
committe got it wrong, then you are as it happens completely at
liberty to join it for C200x.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Serve La]

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:mn********************************@4ax.com...

ISO C is designed to be maximally portable to different hardware and
OSes. Therefore it is a subset of what any given platform can do.

But, has every platform in the world implemented fopen?

[Kelsey Bjarnason]

[snips]

On Tue, 12 Aug 2003 20:58:19 +0000, Richard Heathfield wrote:

So if C knows that little as some people say, what are the benefits,
Portability /and/ power. If you modularise your code so that all the
portable code is separate from the non-portable code, you can move the code
from one implementation to another with a minimum of effort, because you
only have to re-write the non-portable bit.

On the other hand, if C had, say, networking support which it admitted, up
front, wouldn't be available on all implementations, all that would result
is the same sort of situation we have now with the standard library and
freestanding implementations - C code *ain't* guaranteed to work on them,
not if it relies on things only guaranteed to exist on hosted
implementations.

Hence, we could have items such as, say, __STDC_NETWORK__ defined if the
implementation supports the standard networking functions; if it doesn't,
then there would very likely be very little point in trying to build the
app on that implementation in any case: an e-mail client, say, for an
embedded device with no network support makes little sense. That same
e-mail app, however, could now merrily work with any conforming compiler
which _does_ provide the standard networking library.
On one project I worked on - a
browser for embedded systems - a mere 1% of 500,000 lines of code was
non-portable. To move to a new platform (which this company did on a
regular basis), the team needed only to rewrite 5,000 lines of code, all of
which were isolated into a few core modules for easy identification.

Whereas you could probably have simply done a recompile, had C provided a
richer standard library, while admitting that - as with freestanding
implementations - not everyone can do everything.

C seems to take the approach "Daddy must drink milk, because baby can't
eat steak" which seems a tad... weird. Allowing, as it _already_ does,
some aspects of the full library to remain unimplemented on systems where
implementation can't be done, however, hits both sides of the issue; if
you've got networking, your network apps just recompile. If you don't,
well, why are you trying to build a web browser for a non-network-capable
system?

C, for the most part, assumes the coder knows what he's doing - hence
tends to lack a lot of the "safety" features of other languages. Yet when
it comes to the library, C does a complete about-face, assumes the coder
doesn't know what he's doing, assumes he is silly enough to expect
network support on his ABS braking system, or a complete GUI on his Coke
machine and thus decides to avoid the problem by not providing such
support anywhere. This seems very strange: if the coder knows what he's
doing, let _him_ make the decision to include the calls or not; if he
doesn't, then add in the range checking and other safety features.

For all its utility, and as much as I like working with C, its underlying
design mentality seems to be one of multiple and contradictory views.

[Mark McIntyre]

On Wed, 13 Aug 2003 21:52:26 +0200, in comp.lang.c , "Serve La"
<[e-mail]> wrote:

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:mn********************************@4ax.com.. .

ISO C is designed to be maximally portable to different hardware and
OSes. Therefore it is a subset of what any given platform can do.

But, has every platform in the world implemented fopen?

Every platform is required to. It can however simply return NULL.
Luckily an adequately large majority of systems usefully support
opening streams, hence its sufficiently portable.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Robert Wessel]

"Serve La" <[e-mail]> wrote in message news:<bh**********@news2.tilbu1.nb.home.nl>...

But, has every platform in the world implemented fopen?

It has if it claims to be a hosted C implementation. A freestanding C
implementation does not require an implementation of fopen().

Note that fopen() is a C library function. In fact a fully conforming
(albeit not very useful) implementation would be:

FILE *fopen(const char *filename, const char *mode) {return NULL;}

[Richard Heathfield]

Kelsey Bjarnason wrote:

[snips]

On Tue, 12 Aug 2003 20:58:19 +0000, Richard Heathfield wrote:

So if C knows that little as some people say, what are the benefits,
Portability /and/ power. If you modularise your code so that all the
portable code is separate from the non-portable code, you can move the
code from one implementation to another with a minimum of effort, because
you only have to re-write the non-portable bit.

On the other hand, if C had, say, networking support which it admitted, up
front, wouldn't be available on all implementations, all that would result
is the same sort of situation we have now with the standard library and
freestanding implementations - C code *ain't* guaranteed to work on them,
not if it relies on things only guaranteed to exist on hosted
implementations.

Oh, sure, I agree 100%. I'd like the committee to add support for
networking, graphics, sound, and a whole bunch of other stuff. Instead,
though, they potter around with their math extensions (as if anyone cared
about those) and tentatively give us a bool here and a long long there (not
even a very long, which would at least have been scalable).

Hence, we could have items such as, say, __STDC_NETWORK__ defined if the
implementation supports the standard networking functions;
Or even:

TCP *tcp_open(const char *host, unsigned short port);

Returns NULL if the network connection could not be opened. (This is
precisely how my own TCP library works.) It could set errno, for people who
cared about how it failed, e.g. ENONET for "I don't do networks, dummy".
:-)

Same for graphics, sound, etc. The library can always say "no", can't it? So
I don't see what the big deal is. And as for the "lowest common
denominator" being a poor reflection of what you can achieve using heavily
implementation-specific techniques, well, yes, that's true, but irrelevant.
Portability vs power has always been a trade-off in /that/ respect, at
least.
if it doesn't,
then there would very likely be very little point in trying to build the
app on that implementation in any case: an e-mail client, say, for an
embedded device with no network support makes little sense. That same
e-mail app, however, could now merrily work with any conforming compiler
which _does_ provide the standard networking library.
Right. That's how it should be. But we have to deal with reality as it is,
not as we'd like it to be.

<snip>
For all its utility, and as much as I like working with C, its underlying
design mentality seems to be one of multiple and contradictory views.

I don't think it started out that way. :-)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Lew Pitcher]

Jeff wrote:

In article <CZ***************@news20.bellglobal.com>, Lew Pitcher wrote: [snip]

In theory, with the proper hardware, it should be possible to write an
operating system with Standard C.

I don't agree. Some feature can be only implemented in assembly. How can we
access the system register CR0 by C language ?

Let me reiterate...

In theory, /with the proper hardware/, it should be possible to write an
operating system with Standard C.

Obviously, hardware that requires assembly language to access system registers
/is not the proper hardware/.
--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

[Dan Pop]

In <3F***************@sun.com> Eric Sosman <Er*********@sun.com> writes:

Dan Pop wrote:

In <pa***************************@spam.for.me.invalid > "Nils Petter Vaskinn" <[e-mail]> writes:

>But for C to know about filesystems you would have to define functions to
>access that filesystem. While this may seem a good idea now, future
>advances in filesystems (or how OS'es deal with them) may make that
>interface a bad choice.
If well designed and generic enough, this is not going to happen. [...]

The design is the hard part.

It isn't. All you need for the purposes of portable C programming
is getting the name of each item in a directory (except for the
"maintenance" items that might be present, like . and .. on Unix
systems) and a method of deciding whether such an item is an ordinary
file, a directory or neither. The missing bit is a function taking
a path name and an item name and concatenating them to produce a new
valid path name. This is all you need in order to be able to traverse
a full directory tree in a fully portable way. As I said, this can
be trivially achieved with a minimal <dirent.h> and a minimal <stat.h>.
Add the possibility to check whether a directory is "traversable" and
whether an ordinary file is readable/writable/executable by the current
program (additional features of the minimal <stat.h>) and you have
pretty much everything you need for solving a lot of currently
insolvable problems (in standard C) in a fully portable manner.
I'm not sure how this differs from the situation that prevails
today: C offers a "minimal" directory interface (to wit, a null
directory interface), and platforms extend it in various ways.
Obvious answer: with today's "minimal directory interface" you can't do
anything at all. With my proposed minimal interface you can solve most
of the directory access problems arising in the context of portable C
programming.
A less vacuous (is "less vacuous" a linguistic abomination?)
interface would presumably aspire to provide a portable means of
getting at some common subset of all the file-cataloging schemes,
but the big question would be whether that subset could be large
enough to be useful. The Common LISP experience suggests that a
portable interface might be close to impotent, and that a useful
interface might not be very portable.

Please point out the *concrete* problems raised by my proposal above.
I am not interested in the kind of vacuous statements contained in your
previous post.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[The real OS2 guy]

On Tue, 12 Aug 2003 16:20:39 UTC, Martin Marcher <ma*******@gmx.at>
wrote:

Hi,

I've read several questions and often the answer was

'C knows nothing about [lots of different stuff here].'
Absolutely correct.
So if C knows that little as some people say, what are the benefits, I
mean do other languages know more or is it a benefit that C knows nearly
nothing (what I can think about is that C is the largest common divisor
defined on most available platforms)?
Other languages may know more: one language about this, another about
that and so on.

But C is designed to be present on an abstract mashine. That means
that mashine has no real device - but abstract streams, whereas
streams are diveded into:
inputstream - an stream that delivers characters from something
that is able to deliver characters, like
- a terminal with unkown behavior
- a file, where the programmer has no more knowledge
about as it can send a stream of characters
- a pipe
outputstream - a stream that receives characters from the
the program and sends it to somewhere that is able to
receive characters like
- a terminal with unknown behavior
- a file, where the programmer has no more knowledge
about as that it can receive a stream of characters
- a pipe

There are trillions of OSes on the market whereas each OS has its own
set of APIs.
Most of them have at least a C interface - but nothing (except of the
documentation of the OS) exists that defines which APIs are exist,
which kind of parameters, how many parameters and which sequence of
parameters they use. Some OSes have a number of subsystems, each with
theyr own set of APIs. C knows nothing of them! There are some
libraries are around who are fullifies different kints of work (like
linked lists, database access (different kinds of databases),
mathematical functions, different kinds of printers, scanners, tapes,
and so on, and so on... None of them have to do a bit with C - except
that many have interfaces, designed to be used by C programs.

Many of them are written in C with some properitary extensions
included, some are written in other programming languages, but with
interfaces to C programs included.
This question came to my mind when I was reading "Serial Number of the
Hard Drive" (Message ID: bh************@ID-191020.news.uni-berlin.de).
Because I often read 'Unix is written in C' I'm asking myself how an OS
can be written in C if it knows nothing about anything.
Oh yes, C knows absolutely nothing about that - but the OS has sets of
APIs, designed to be used from C programs. One or more of that is able
to ask the OS for the required information, others to write it, .....

C is a land of a programming language designed to be extended to do
anything a programmer may ever have in mind. But each extension is
more or less properitary and is NOT simply C as defined by the ANSI
standard. Many of thiese extensions have theyr own newsgroup (or more
than one!) whereas this extension is on topic.

C itself is nothing than a naked language with some syntax
constraints, a set of rules to programmers of C compilers, C
implementations, hosted and free standing environments and a bit less
strong for programmers of applications.

A free standing environment is an environment whereas is nothing known
than the hardware a C program has to run on. This means: absolutely no
I/O (as C knows absolutely nothing about devices), a minimum about
pointers (accessing a NULL pointer results in undefined behavior, a
NULL pointer is defined INSIDE a C source as binary 0 - even as the
mashine itself may use some other bitpattern to represent it (it is on
the compiler to make a binary 0 comparing to this bitpattern in
pointer context).

A hosted environment has knowledge about the underlying OS, so it can
use it to make the streams to connecting and correspondence to the
device in a standardised manner. The OS can, but must not deliver a
more complex set of APIs to C programs - but thiese are only
interfaces, defined by the OS, not the C.

And please stay on the newbiest level possible so I can understand that or
just tell me to wait 'till I learned more :)

All that above can be reduced to:
comp.lang.c handles the language C and its assigned standard library -
but it has nothing to do with properitary interfaces to a spezific OS
or device or library.

You may use C to write an OS (then you uses a free standing
environment, whereas you has to write any bit of I/O by yourself).

You may use C as defined by the ANSI C standard(s) (there are more
than one created over the years C exists now). Then you can use the
standard C library. Whereas the C library itself defines a set of APIs
to make some basic things (e.g. string handling, memory handling,
streamed IO and so on). All these is on topic here.

You may use C in the way your OS extends it - but this lts you alone
in one of the newsgrous defined to programm with the OS you're working
under, as this has nothing to do with C. You may use some libraries
created for doing special work - but then you have to find a newsgroup
that handles this specific library, because this library has nothing
to do with C, even if it is written itself in C.

That is because the language C and its standard library
- is itself complex enough to justify its own newsgroup
- knows nothing about real devices, because
handling with real devices is object of the OS
and the real hardware and has nothing to do with C
- is designed to work on an abstract mashine
that defines anything one needs to write a
C program in, whereas a C compiler for a
real mashine is able to produce code running
on it. It will give you more or less possibilities
to use properitary extensions - but these extensions
are not C as defined by the standard and unportable.
- is designed to be portable to any real mashine
that ever had/will be exist. But it lefts open
anything that is only defineable on a real mashine.
So using something that is only defined on a
properitary mashine makes the program incompatible and
at least unportable - and so you leaves the standard.

In short: Whenever you have a question about C, you're
welcome here. Whenever you have a question about something
C knows nothing about you have to go to a group that
knows about that.

--
Tschau/Bye

Herbert Rosenau
http://www.pc-rosenau.de eComStation Reseller in Germany
eCS 1.1 german is in beta testing

[Dan Pop]

In <3F***************@sun.com> Eric Sosman <Er*********@sun.com> writes:

Dan Pop wrote:

In <3F***************@sun.com> Eric Sosman <Er*********@sun.com> writes:

>Dan Pop wrote:
>>
>> In <pa***************************@spam.for.me.invalid > "Nils Petter Vaskinn" <[e-mail]> writes:
>>
>> >But for C to know about filesystems you would have to define functions to
>> >access that filesystem. While this may seem a good idea now, future
>> >advances in filesystems (or how OS'es deal with them) may make that
>> >interface a bad choice.
>>
>> If well designed and generic enough, this is not going to happen. [...]
>
> The design is the hard part.
It isn't. All you need for the purposes of portable C programming
is getting the name of each item in a directory (except for the
"maintenance" items that might be present, like . and .. on Unix
systems) and a method of deciding whether such an item is an ordinary
file, a directory or neither. The missing bit is a function taking ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

a path name and an item name and concatenating them to produce a new ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^ valid path name. This is all you need in order to be able to traverse ^^^^^^^^^^^^^^^ a full directory tree in a fully portable way. As I said, this can
be trivially achieved with a minimal <dirent.h> and a minimal <stat.h>.
Add the possibility to check whether a directory is "traversable" and
whether an ordinary file is readable/writable/executable by the current
program (additional features of the minimal <stat.h>) and you have
pretty much everything you need for solving a lot of currently
insolvable problems (in standard C) in a fully portable manner.

Are you proposing an interface that's only able to discover
existing files, but not able to synthesize names for new ones?

Are you reading impaired or what?

> I'm not sure how this differs from the situation that prevails
>today: C offers a "minimal" directory interface (to wit, a null
>directory interface), and platforms extend it in various ways.

Obvious answer: with today's "minimal directory interface" you can't do
anything at all. With my proposed minimal interface you can solve most
of the directory access problems arising in the context of portable C
programming.

It's not clear what you mean by "portable" here. Obviously,

The obvious: people need to do that in otherwise portable code and
currently they cannot. With my proposal above, it becomes possible,
without sacrificing the code portability.

>A less vacuous (is "less vacuous" a linguistic abomination?)
>interface would presumably aspire to provide a portable means of
>getting at some common subset of all the file-cataloging schemes,
>but the big question would be whether that subset could be large
>enough to be useful. The Common LISP experience suggests that a
>portable interface might be close to impotent, and that a useful
>interface might not be very portable.

Please point out the *concrete* problems raised by my proposal above.
I am not interested in the kind of vacuous statements contained in your
previous post.

Your proposal amounts to "readdir() is The Answer," and that's
hardly a *concrete* proposal until it's augmented with a good deal
more detail.

All the detail is, in shematic form, presented at the beginning of
my previous post (and still visible in this post). It's downright
idiotic to summarise it as "readdir is The Answer". There is no
point in giving concrete function and macro names *before* the idea
is accepted.
A good design for such a facility seems difficult to me, but
you say it's simple.
You have completely failed to produce a valid criticism of my
proposal or to point out why it would cause implementation
difficulties on systems where implementing it would make any sense
in the first place.
Fine: different people have different levels
of ability and imagination, and what's hard for me may be easy
for you. If that's the case, I hope you will share your simple
and useful design with the committee that next revises the Standard
for the benefit of C programmers everywhere.

It would be a waste of time, as long as the committee insists that a
*minimal* file system interface (as described above) does not belong to
the standard.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de