Malloc

[Richard Tobin]

This not only doesn't follow, but is demonstrably false since a great
many utility functions can be written in standard C.

Certainly some can. But of the 37 unix utilities in /bin on this
machine, most can't be. Standard C's complete unawareness of
directories is one cause.

Even the ones that can apparently be written have subtleties that make
them not quite right. For example, should "cat" open files in binary
or text mode? I'm doubtful that any of them can be perfectly
implemented in standard C. Of course, they can still be useful
utilities.

-- Richard

 

[Yevgen Muntyan]

Mark McIntyre wrote: [...]

If your programme definitely needs to know precisely how your OS is
choosing and allocating memory, it may be that C is the wrong language
to use.

Why? Most of the OSes are written in C.

In clc, "the C language" means "as defined by the ISO standard".
More precisely, what he probably meant was "you will need to go
outside the scope of the standard, and use some system- specific
methods to do what you need". Whether that means using C for most
of your work, plus using some implementation-specific additions,
or using a different language entirely, is up to you.

The following program is a C program:

#include <sys/stat.h>
#include <fcntl.h>
int main (void)
{
open("foobar", O_RDONLY);
return 0;
}

C standard doesn't say what it does (or if it does anything), and
it is off-topic here, but it *is* a C program. There is huge difference
between "off-topic in comp.lang.c" and "not the C language". Note that
the standard doesn't say that the program above is not a C program, and
it does admit that it *can* be a valid program. And for many humans
(apparently not for all), it actually *is* a C program.

You know, saying that "C language" means here "as defined by the ISO
standard" is silly, because it's the very definition of C language
(accepted by many at least, otherwise we don't have what to talk about).
Moreover, saying that "C language" means something special in this
newsgroup actually makes the newsgroup look stupid - like "those folks
invented their own language and call it C".

What you said is really similar in its value to the opposite "how do u
download a file in C/C++". (The explanation was better, but then how
do you compile your "the C" programs? Using implementation-specific
compiler or linker or frobnicator, right?)

Yevgen

 

[CBFalconer]

Kenneth Brody escreveu:

Mark McIntyre wrote:

[...]
If your programme definitely needs to know precisely how your
OS is choosing and allocating memory, it may be that C is the
wrong language to use.

Why? Most of the OSes are written in C.

In clc, "the C language" means "as defined by the ISO standard".
More precisely, what he probably meant was "you will need to go
outside the scope of the standard, and use some system- specific
methods to do what you need". Whether that means using C for
most of your work, plus using some implementation-specific
additions, or using a different language entirely, is up to you.

That, and I have no idea what percentage of operating systems
are written in C. However, given clc's definition of C, I would
venture that, as far as clc is concerned, no true "operating
system" is, or possibly even could be, written in standard C.

Interesting position! Taken to the ultimate: no useful program
has been written in Standard C!

You omitted the word 'entirely'. In general an OS can be written
in C, apart from the 5% or so of system dependant functions. For
example, mucking with a stack pointer, in a stack based system, is
not possible in pure C, and will require an assembly language
function. However that can be called from C, if designed
appropriately. Similarly for access to i/o ports. It doesn't take
many of these functions to enable OS construction, and the result
is highly portable, but not completely portable. In Linux and Unix
the sbrk function exists primarily to enable construction of the
malloc family. In turn, malloc exists to couple whatever the OS
provides to the language standards.

The same can be said for many other languages. C happens to be
very close to the bare machine, and thus requires the least
assistance (so far). Other languages have also been used as the
base, with success. Look up Concurrent Pascal and the Solo System.

 

[Ian Collins]

You omitted the word 'entirely'. In general an OS can be written
in C, apart from the 5% or so of system dependant functions. For
example, mucking with a stack pointer, in a stack based system, is
not possible in pure C, and will require an assembly language
function. However that can be called from C, if designed
appropriately. Similarly for access to i/o ports. It doesn't take
many of these functions to enable OS construction, and the result
is highly portable, but not completely portable. In Linux and Unix
the sbrk function exists primarily to enable construction of the
malloc family. In turn, malloc exists to couple whatever the OS
provides to the language standards.

The same can be said for many other languages. C happens to be
very close to the bare machine, and thus requires the least
assistance (so far). Other languages have also been used as the
base, with success. Look up Concurrent Pascal and the Solo System.

My favourite was RSTS/E for the PDP-11, written largely in BASIC-Plus.

 

[Dik T. Winter]

>
> Certainly some can. But of the 37 unix utilities in /bin on this
> machine, most can't be. Standard C's complete unawareness of
> directories is one cause.

How would you open a directory on a system that does not know about
directories?

> Even the ones that can apparently be written have subtleties that make
> them not quite right. For example, should "cat" open files in binary
> or text mode?

Or should it open the resource fork or the data fork? Or what if some
of the files are fixed size records (of different sizes) and others are
Z-type records?

You stated it quite clear "unix utilities". You are not talking about
general utilities but about OS specific utilities. It is obvious that
when part of the specification is OS specific, that it can not be
written in standard C.

 

[Default User]

Cesar Rabak wrote:

Interesting position! Taken to the ultimate: no useful program has
been written in Standard C!

I rewrote my text-adventure game to be 100% ISO C89. I like to think
it's useful. It still has some functions that rely on implicit
declaration, so it's not yet c99 compliant.




Brian

 

[Flash Gordon]

Dik T. Winter wrote, On 04/02/07 03:08:

How would you open a directory on a system that does not know about
directories?

The same as trying to open a file that does not exist, it fails. The
standard *could* have provided a method for getting a list of files
where the "file list open" function took a name that the implementation
treated as it wished with no guarantee that the "file list open"
function would succeed (just as fopen can fail) and no guarantee that
you can open the files that are listed. The standard committee choose
not to do this, but they could have. Note that I have not specified that
the list if files is a directory, nor have I specified that you must be
able to get a list of files.

Or should it open the resource fork or the data fork? Or what if some
of the files are fixed size records (of different sizes) and others are
Z-type records?

You stated it quite clear "unix utilities". You are not talking about
general utilities but about OS specific utilities. It is obvious that
when part of the specification is OS specific, that it can not be
written in standard C.

The statement "unix utilities" was because they are utilities that are
traditionally provided on Unix like systems, not because they rely on
unix. Unless you think that reading a file (name specified on the
command line) and sending the output to stdout relies on some Unix
specifics (if so what), or reading stdin and sending the output to both
a file (named on the command line) and stdout depends on some unix
specific call, or...

There are a number of "unix utilities" that do not rely on anything that
is specific to Unix even though they are provided with Unix type
systems. The ones I am thinking of are specifically designed to operate
on text files so should open the file in text mode and if it is not a
text file the user gets what s/he deserves.

<snip>

I would say open as text mode. However, you could always add a switch to
specify whether the file(s) should be opened in text or binary mode and
it would be just as (or more) useful.

 

[Christopher Layne]

There are a number of "unix utilities" that do not rely on anything that
is specific to Unix even though they are provided with Unix type
systems. The ones I am thinking of are specifically designed to operate
on text files so should open the file in text mode and if it is not a
text file the user gets what s/he deserves.

There is no text mode on unix systems.

<snip>

I would say open as text mode. However, you could always add a switch to
specify whether the file(s) should be opened in text or binary mode and
it would be just as (or more) useful.

There is no text mode on unix systems.

 

[Joe Wright]

Dik T. Winter wrote, On 04/02/07 03:08:

The same as trying to open a file that does not exist, it fails. The
standard *could* have provided a method for getting a list of files
where the "file list open" function took a name that the implementation
treated as it wished with no guarantee that the "file list open"
function would succeed (just as fopen can fail) and no guarantee that
you can open the files that are listed. The standard committee choose
not to do this, but they could have. Note that I have not specified that
the list if files is a directory, nor have I specified that you must be
able to get a list of files.


The statement "unix utilities" was because they are utilities that are
traditionally provided on Unix like systems, not because they rely on
unix. Unless you think that reading a file (name specified on the
command line) and sending the output to stdout relies on some Unix
specifics (if so what), or reading stdin and sending the output to both
a file (named on the command line) and stdout depends on some unix
specific call, or...

There are a number of "unix utilities" that do not rely on anything that
is specific to Unix even though they are provided with Unix type
systems. The ones I am thinking of are specifically designed to operate
on text files so should open the file in text mode and if it is not a
text file the user gets what s/he deserves.


<snip>

I would say open as text mode. However, you could always add a switch to
specify whether the file(s) should be opened in text or binary mode and
it would be just as (or more) useful.

Modes 'text' and 'binary' have little or no meaning on Unix. Also, it
makes little sense to 'cat' binary files.

 

[Richard Heathfield]

Christopher Layne said:

There is no text mode on unix systems.

If that were true, which it is not, fopen("file", "w") could never succeed
on Unix, which it does. There is *too* a text mode on Unix systems, so
there.

<snip>

 

[Ben C]

Modes 'text' and 'binary' have little or no meaning on Unix. Also, it
makes little sense to 'cat' binary files.

Not to a terminal, but I've used

$ cat x* >> file

for example, to put back together what split has split.

 

[Cesar Rabak]

CBFalconer escreveu:

Kenneth Brody escreveu:

santosh wrote:
Mark McIntyre wrote:

[...]
If your programme definitely needs to know precisely how your
OS is choosing and allocating memory, it may be that C is the
wrong language to use.
Why? Most of the OSes are written in C.
In clc, "the C language" means "as defined by the ISO standard".
More precisely, what he probably meant was "you will need to go
outside the scope of the standard, and use some system- specific
methods to do what you need". Whether that means using C for
most of your work, plus using some implementation-specific
additions, or using a different language entirely, is up to you.

That, and I have no idea what percentage of operating systems
are written in C. However, given clc's definition of C, I would
venture that, as far as clc is concerned, no true "operating
system" is, or possibly even could be, written in standard C.

Interesting position! Taken to the ultimate: no useful program
has been written in Standard C!

You omitted the word 'entirely'.

Chuck, how could I have omitted a word that has not being written? See
above text.

In general an OS can be written
in C, apart from the 5% or so of system dependant functions.

I'm on this vital industry¹ for almost 30 years to say that your phrase
above does not include "Standard C"

For
example, mucking with a stack pointer, in a stack based system, is
not possible in pure C, and will require an assembly language
function. However that can be called from C, if designed
appropriately. Similarly for access to i/o ports. It doesn't take
many of these functions to enable OS construction, and the result
is highly portable, but not completely portable.

More or less, but see:

In Linux and Unix
the sbrk function exists primarily to enable construction of the
malloc family. In turn, malloc exists to couple whatever the OS
provides to the language standards.

To make my point and not span the whole industry: let's take two short
examples:

in the time part of the Solaris OS was distributed with source and part
of its installation required compiling, even after ANSI 1989, it was not
conformant for a long time.

there was a time gcc had to include a 'bug' in order Linux kernel could
be compiled. It still an adventure for the brave to attempt to compile
the Linux kernel with any other compiler than gcc².

The same can be said for many other languages. C happens to be
very close to the bare machine, and thus requires the least
assistance (so far). Other languages have also been used as the
base, with success. Look up Concurrent Pascal and the Solo System.

I agree.

--
Cesar Rabak


[1] For context: it comes from one of the Woodpecker's cartoon shows!

[2] which you (Chuck) should know a lot as I see you at the OW list, for
example!

 

[Richard Tobin]

How would you open a directory on a system that does not know about
directories?

First, I wasn't criticising the C standard for not supporting this.
Just observing that a lot of simple utilities can't be written in
standard C.

Second, many languages *do* provide directory access as part of the
language (rather than an add-on like Posix). Presumably
implementations on systems without directories can't implement that
part of the language, or else the language specifies what to do in
such a case. C chose not to do it - it wasn't forced.

-- Richard

 

[Richard Tobin]

Even the ones that can apparently be written have subtleties that make
them not quite right. For example, should "cat" open files in binary
or text mode? [...]

I would say open as text mode. However, you could always add a switch to
specify whether the file(s) should be opened in text or binary mode and
it would be just as (or more) useful.

[/QUOTE]

Modes 'text' and 'binary' have little or no meaning on Unix.

That was the point. Text and binary mode are, if you like, the same
on Unix. But if you try to implement "cat" in standard C, you have to
decide what mode to use to open a file, so when you run it on other
systems it may be wrong. Of course, one might reasonably conclude that
this is an advantage of the Unix model of files.

Also, it makes little sense to 'cat' binary files.

cat has many uses apart from displaying a file. Some of them are
sometimes relevant for binary files.

-- Richard

 

[Flash Gordon]

Richard Heathfield wrote, On 04/02/07 15:24:

Christopher Layne said:


If that were true, which it is not, fopen("file", "w") could never succeed
on Unix, which it does. There is *too* a text mode on Unix systems, so
there.

It just happens that on most, if not all, Unix like systems it does not
make any difference whether you open a file in text or binary mode. So
specifying text mode on Unix like systems does not harm on Unix like
systems but makes it work correctly (for certain values of correct) on
non-Unix like systems such as DOS, Windows, MacOS 9 etc.

 

[Flash Gordon]

Ben C wrote, On 04/02/07 15:25:

Not to a terminal, but I've used

$ cat x* >> file

for example, to put back together what split has split.

I've used it for other reasons on binary files and I agree it is useful.
This is why I suggested that portably implementing such programs you
might want to be able to specify text or binary on the command line.
Then you can get the best of both worlds on the non-Unix like systems
where there is a difference.

 

[Flash Gordon]

Richard Tobin wrote, On 04/02/07 18:38:

Even the ones that can apparently be written have subtleties that make
them not quite right. For example, should "cat" open files in binary
or text mode? [...]

[/QUOTE]

I wrote the following bit.

That was the point. Text and binary mode are, if you like, the same
on Unix. But if you try to implement "cat" in standard C, you have to
decide what mode to use to open a file, so when you run it on other
systems it may be wrong. Of course, one might reasonably conclude that
this is an advantage of the Unix model of files.

Well, my point was that having to decide on systems where, unlike Unix,
there is a difference is not a problem and my solution to it uses only
standard C and does not cause a problem on Unix like systems.

cat has many uses apart from displaying a file. Some of them are
sometimes relevant for binary files.

Agreed, and I have used cat on binary files. Admittedly I was not
thinking about that in my post quoted here, but I did allow for it.

 

[Richard Heathfield]

Richard Tobin said:

First, I wasn't criticising the C standard for not supporting this.
Just observing that a lot of simple utilities can't be written in
standard C.

Second, many languages *do* provide directory access as part of the
language (rather than an add-on like Posix). Presumably
implementations on systems without directories can't implement that
part of the language, or else the language specifies what to do in
such a case. C chose not to do it - it wasn't forced.

Rather, C chose to leave such matters in the care of OS-specific libraries,
contenting itself with providing a very flexible mechanism (the function
call) for interfacing with such libraries.

 

[Mark McIntyre]

CBFalconer escreveu:

Chuck, how could I have omitted a word that has not being written? See
above text.

Thats "omitted" as in "you should have included the word, in order for
your statement to be factually accurate, as it was written it was
false".

I'm on this vital industry¹ for almost 30 years to say that your phrase
above does not include "Standard C"

I'm having trouble parsing that, but if it reads as "I have 30 years
experience and disagree" then thats your right, but it can be
trivially proven so you're probably onto a loser.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Cesar Rabak]

Mark McIntyre escreveu:
Humm... are you willing to play a wording game, where a simple subset of
the Standard sanctions as compliant?

Thats "omitted" as in "you should have included the word, in order for
your statement to be factually accurate, as it was written it was
false".


I'm having trouble parsing that, but if it reads as "I have 30 years
experience and disagree" then thats your right, but it can be
trivially proven so you're probably onto a loser.

Waiting your trivial proof.

BTW:

Meanwhile, just a remark as how you start to be offensive when you
cannot sustain an argument on logical base.

*PLONK*