Is this code correct
char *str = (char *)malloc(10 * sizeof(char));
char[0] = ...
char [1] = ...
....
....
...
char [9] = '\0';
malloc() does not make any guarantees regarding the contiguity of
memory. In that case, is ths code correct? Can we assume that the
characters are contiguous in memory.
96  3360 
pavan <pa********@gmail.comwrote:
malloc() does not make any guarantees regarding the contiguity of
memory.
Why do you think this is the case ?
--
:wq
^X^Cy^K^X^C^C^C^C
On Feb 3, 11:15 am, Ico <use...@zeev.nlwrote:
pavan <pavan.m...@gmail.comwrote:
malloc() does not make any guarantees regarding the contiguity of
memory.
Why do you think this is the case ?
--
:wq
^X^Cy^K^X^C^C^C^C
if i create a chunk of memory containing a number of elements of the
same type, i want to know if i can access the elements as ptr, ptr+1,
ptr+2 etc... Should I use vmalloc() instead of malloc if i want to do
this?
pavan wrote:
On Feb 3, 11:15 am, Ico <use...@zeev.nlwrote:
pavan <pavan.m...@gmail.comwrote:
malloc() does not make any guarantees regarding the contiguity of
memory.
Why do you think this is the case ?
if i create a chunk of memory containing a number of elements of the
same type, i want to know if i can access the elements as ptr, ptr+1,
ptr+2 etc...
Yes, you can.
Should I use vmalloc() instead of malloc if i want to do this?
No. vmalloc() is a non-standard function. malloc() is fine.
Does this mean that malloc returns memory that is contiguous in
virtual address space?
pavan wrote:
Is this code correct
char *str = (char *)malloc(10 * sizeof(char));
char[0] = ...
char [1] = ...
I hope you mean str[0], str[1] etc.? char is a type. Types are not
directly usable. You must have an object of a type, to use it.
...
...
..
char [9] = '\0';
malloc() does not make any guarantees regarding the contiguity of
memory.
Where do get this nonsense from. A chunk of memory returned by
malloc() calloc() or realloc() can be regarded as an array, which is
by definition contiguous.
In that case, is ths code correct? Can we assume that the
characters are contiguous in memory.
Yes. Elements in a block allocated by a single call to *alloc() can be
regarded as sequential.
pavan wrote:
Does this mean that malloc returns memory that is contiguous in
virtual address space?
>From the point of view of a C program, it is contiguous. Whether it's
so in virtual/physical/whatever memory is outside the scope of C and
moreover, totally irrelevant to most C programs.
pavan wrote:
Is this code correct
char *str = (char *)malloc(10 * sizeof(char));
Don't cast the result of malloc. The sizeof(char) is redundant, as
sizeof(char) is always 1.
char[0] = ...
char [1] = ...
....
....
...
char [9] = '\0';
malloc() does not make any guarantees regarding the contiguity of
memory.
Of course it does, who told you otherwise?
In that case, is ths code correct? Can we assume that the
characters are contiguous in memory.
--
Clark S. Cox III cl*******@gmail.com
pavan wrote:
Does this mean that malloc returns memory that is contiguous in
virtual address space?
As far as any conforming C program is concerned, malloc returns
contiguous memory. Period.
--
Clark S. Cox III cl*******@gmail.com
On 3 Feb 2007 08:29:50 -0800, in comp.lang.c , "pavan"
<pa********@gmail.comwrote:
>Does this mean that malloc returns memory that is contiguous in
virtual address space?
The C language doesn't need to know anything about how the OS lays out
memory in any virtual address space. As far as C is concerned, any
memory returned by malloc is a contiguous block.
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.
--
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
pavan said:
Is this code correct
char *str = (char *)malloc(10 * sizeof(char));
char[0] = ...
char [1] = ...
...
...
..
char [9] = '\0';
No. Wrap it in a function, lose the cast, add a check to determine whether
str is NULL after the malloc call, change sizeof(char) to sizeof *str,
#include <stdlib.hand change char[0] etc to str[0] etc, and you'll have
something you can use.
malloc() does not make any guarantees regarding the contiguity of
memory.
"The order and contiguity of storage allocated *by successive calls*
to the calloc , malloc , and realloc functions is unspecified." Since malloc
can be used to allocate storage for any object, we may deduce that the
storage thus allocated in a single call is contiguous.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mark McIntyre wrote:
On 3 Feb 2007 08:29:50 -0800, in comp.lang.c , "pavan"
<pa********@gmail.comwrote:
Does this mean that malloc returns memory that is contiguous in
virtual address space?
The C language doesn't need to know anything about how the OS lays out
memory in any virtual address space. As far as C is concerned, any
memory returned by malloc is a contiguous block.
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.
pavan a écrit :
Does this mean that malloc returns memory that is contiguous in
virtual address space?
Yes
pavan wrote:
>
Is this code correct
char *str = (char *)malloc(10 * sizeof(char));
char[0] = ...
char [1] = ...
...
...
..
char [9] = '\0';
malloc() does not make any guarantees regarding the contiguity of
memory. In that case, is ths code correct? Can we assume that the
characters are contiguous in memory.
Yes you can, but you should correct your call on malloc.
sizeof(char) is 1 by definition, and the only function of the cast
is to suppress the needed error message which will point out the
failure to #include <stdlib.h>. A better phrase would be:
char *str = malloc(10 * sizeof *str);
which can be retyped by changing only the "char", and will not
suppress any error messages.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
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.
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
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!
>Kenneth Brody escreveu:
[snippage]
>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.
Not a useful one, anyway, for most definitions of "useful". :-)
In article <eq**********@aioe.orgCesar Rabak <cs*****@yahoo.com.brwrote:
>Interesting position! Taken to the ultimate: no useful program has been
written in Standard C!
This, like the above, depends on one's definition of "useful".
int main(void) {
return 0; /* or include <stdlib.hand return EXIT_SUCCESS */
}
is a Standard C program, and is actually quite useful on various
sytems, including IBM OSes (where it functions identically to
IEFBR14) and Unix-like OSes (where it functions identically to
"true", typically found in /bin or /usr/bin).
Some of the Unix utilities (grep, uniq, sed, and so forth) can also
be written in strictly conforming hosted C, although for various
reasons, many use various system-specific bits anyway.
If your definition of "useful" requires GUI-ness and WYSIWYG-ness
and other such items, however, then yes, no "useful" program can
be written in Standard C. Fortunately, you can always specify "ISO
9899:1990 plus <other standard>" to get an environment that works
only on the intersection set of systems: those that support both
C90 and the other standard. This is likely to be fewer systems
than "those that support C90", but as long as the intersection is
not empty, you can proceed.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Cesar Rabak wrote, On 03/02/07 22:56:
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!
Wrong. Lots of small but very useful programs have been written in
standard C. However, the vast majority of programs need a small amount
of code that is not standard C.
--
Flash Gordon
On 3 Feb 2007 08:48:22 -0800, in comp.lang.c , "santosh"
<sa*********@gmail.comwrote:
>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.
Parts of them maybe. But anything that has to know about precise
memory addresses is written in some c-ish dialect of Hardwarese.
--
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
On Sat, 03 Feb 2007 20:56:46 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:
>Kenneth Brody escreveu:
>santosh wrote:
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!
This not only doesn't follow, but is demonstrably false since a great
many utility functions can be written in standard C.
--
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
In article <q2********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Kenneth Brody wrote:
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.
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
Cesar Rabak wrote:
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'. 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.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
CBFalconer wrote:
Cesar Rabak wrote:
>>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.
My favourite was RSTS/E for the PDP-11, written largely in BASIC-Plus.
--
Ian Collins.
In article <eq***********@pc-news.cogsci.ed.ac.uk ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <q2********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
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.
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.
>
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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
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
Dik T. Winter wrote, On 04/02/07 03:08:
In article <eq***********@pc-news.cogsci.ed.ac.ukri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <q2********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
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.
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.
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.
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.
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.
<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.
--
Flash Gordon
Flash Gordon wrote:
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.
> 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.
<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.
Flash Gordon wrote:
Dik T. Winter wrote, On 04/02/07 03:08:
>In article <eq***********@pc-news.cogsci.ed.ac.uk>
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
> In article <q2********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:
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.
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.
> 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.
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.
> 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.
<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.
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Christopher Layne said:
Flash Gordon wrote:
>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.
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>
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
On 2007-02-04, Joe Wright <jo********@comcast.netwrote:
[snip]
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.
CBFalconer escreveu:
Cesar Rabak wrote:
>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!
In article <JC********@cwi.nl>, Dik T. Winter <Di********@cwi.nlwrote:
>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.
>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
In article <E_******************************@comcast.com>,
Joe Wright <jo********@comcast.netwrote:
>> 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.
>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Richard Heathfield wrote, On 04/02/07 15:24:
Christopher Layne said:
>Flash Gordon wrote:
>>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.
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:
On 2007-02-04, Joe Wright <jo********@comcast.netwrote:
[snip]
>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.
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:
In article <E_******************************@comcast.com>,
Joe Wright <jo********@comcast.netwrote:
>>> 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 wrote the following bit.
>>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.
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.
>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.
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.
--
Flash Gordon
Richard Tobin said:
In article <JC********@cwi.nl>, Dik T. Winter <Di********@cwi.nlwrote:
<snip>
>>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.
<shrug>And a lot can.</shrug>
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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
On Sun, 04 Feb 2007 14:09:32 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:
>CBFalconer escreveu:
>Cesar Rabak wrote:
>>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.
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".
>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"
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
Mark McIntyre escreveu:
On Sun, 04 Feb 2007 14:09:32 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:
>CBFalconer escreveu:
>>Cesar Rabak wrote:
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.
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".
>>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"
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*
Flash Gordon wrote:
Ben C wrote, On 04/02/07 15:25:
>Joe Wright <jo********@comcast.netwrote:
[snip]
>>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.
Which may well foul the file on a non-Unix system.
>
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.
Here is an extract from one of my programs, where the input can be
either binary or text. Redirection causes text input, but a file
specification forces binary input. The technique may be of
interest. Notice that cat can put together a mess of text files,
so that no more than a single text file input is generally needed.
int main(int argc, char **argv)
{
FILE *f;
f = stdin;
if (3 == argc) {
if (!(f = fopen(argv[2], "rb"))) {
printf("Can't open %s\n", argv[2]);
exit(EXIT_FAILURE);
}
argc--;
}
if (2 != argc) {
puts("Usage: binfsrch name [binaryfile]");
puts(" (file defaults to stdin text mode)");
}
else if (binfsrch(argv[1], f)) {
printf("\"%s\" : found\n", argv[1]);
}
else printf("\"%s\" : not found\n", argv[1]);
printf("%lu chars\n", (unsigned long)chrcount);
return 0;
} /* main binfsrch */
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
CBFalconer wrote:
Flash Gordon wrote:
Ben C wrote, On 04/02/07 15:25:
Joe Wright <jo********@comcast.netwrote:
[snip]
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.
Which may well foul the file on a non-Unix system.
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.
Here is an extract from one of my programs, where the input can be
either binary or text. Redirection causes text input, but a file
specification forces binary input. The technique may be of
interest. Notice that cat can put together a mess of text files,
so that no more than a single text file input is generally needed.
int main(int argc, char **argv)
{
FILE *f;
f = stdin;
Is this assignment guaranteed to be portable?
<snip>
santosh said:
CBFalconer wrote:
<snip>
>int main(int argc, char **argv)
{
FILE *f;
f = stdin;
Is this assignment guaranteed to be portable?
Its effect (a diagnostic message from your implementation) is indeed
fully portable.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
santosh wrote:
CBFalconer wrote:
int main(int argc, char **argv)
{
FILE *f;
f = stdin;
Is this assignment guaranteed to be portable?
Yes, there's nothing wrong with it.
Richard Heathfield wrote:
santosh said:
CBFalconer wrote:
<snip>
int main(int argc, char **argv)
{
FILE *f;
f = stdin;
Is this assignment guaranteed to be portable?
Its effect (a diagnostic message from your implementation) is indeed
fully portable.
It was specified as an extract from a program, so no, a diagnostic is
not required (and typically not emitted), as long as <stdio.his
included earlier.
Harald van D?k said:
Richard Heathfield wrote:
>santosh said:
CBFalconer wrote:
<snip>
>int main(int argc, char **argv)
{
FILE *f;
f = stdin;
Is this assignment guaranteed to be portable?
Its effect (a diagnostic message from your implementation) is indeed
fully portable.
It was specified as an extract from a program,
So it was. My apologies to Chuck - *again*. Sheesh, Chuck, I swear you
do it on purpose.
so no, a diagnostic is
not required (and typically not emitted), as long as <stdio.his
included earlier.
Right.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Richard Heathfield wrote:
santosh said:
>CBFalconer wrote:
<snip>
>>int main(int argc, char **argv)
{
FILE *f;
f = stdin;
Is this assignment guaranteed to be portable?
Its effect (a diagnostic message from your implementation) is
indeed fully portable.
You are slipping:
>From N869:
7.19 Input/output <stdio.h>
7.19.1 Introduction
[#1] The header <stdio.h declares three types, several
macros, and many functions for performing input and output.
[#2] The types declared are size_t (described in 7.17);
FILE
which is an object type capable of recording all the
information needed to control a stream, including its file
position indicator, a pointer to its associated buffer (if
any), an error indicator that records whether a read/write
error has occurred, and an end-of-file indicator that
records whether the end of the file has been reached; and
.... snip ...
stderr
stdin
stdout
which are expressions of type ``pointer to FILE'' that point
to the FILE objects associated, respectively, with the
standard error, input, and output streams.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
In article <11**********************@p10g2000cwp.googlegroups .com>,
santosh <sa*********@gmail.comwrote:
> f = stdin;
>Is this assignment guaranteed to be portable?
The semantics of assignment and of argument-passing are essentially
the same, and it would be absurd if you could not pass stdin as an
argument.
Were you perhaps thinking of assigning *to* stdin?
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
"Default User" <de***********@yahoo.comwrote:
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.
Link?
Richard
Richard Tobin wrote:
In article <11**********************@p10g2000cwp.googlegroups .com>,
santosh <sa*********@gmail.comwrote:
f = stdin;
Is this assignment guaranteed to be portable?
The semantics of assignment and of argument-passing are essentially
the same, and it would be absurd if you could not pass stdin as an
argument.
Were you perhaps thinking of assigning *to* stdin?
Yes. Apologies to the others as well. I got mixed up there. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: john smith |
last post by:
Can someone please explain to me what is happening when I do a malloc(0).
This is what I did.
int* p = (int*)malloc(0);
Then I printed the value of p and of course it was non-null.
But...
|
by: Richard Hunt |
last post by:
I'm sorry for asking such a silly question, but I can't quite get my head
around malloc. Using gcc I have always programmed in a lax C/C++ hybrid
(which I suppose is actually c++). But I have...
|
by: Brian Blais |
last post by:
Hello,
I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like:
d=(double *) malloc(50*sizeof(double));
why is this bad? I had always thought...
|
by: Rano |
last post by:
/*
Hello,
I've got some troubles with a stupid program...
In fact, I just start with the C language and sometime
I don't understand how I really have to use malloc.
I've readden the FAQ...
|
by: spasmous |
last post by:
main()
{
float * f;
initialize_f(f);
// ...use f for processing
free(f);
}
|
by: Martin Jørgensen |
last post by:
Hi,
I have a (bigger) program with about 15-30 malloc's in it (too big to
post it here)... The last thing I tried today was to add yet another
malloc **two_dimensional_data. But I found out that...
|
by: James Dow Allen |
last post by:
The gcc compiler treats malloc() specially! I have no
particular question, but it might be fun to hear from
anyone who knows about gcc's special behavior.
Some may find this post interesting;...
|
by: Why Tea |
last post by:
What happens to the pointer below?
SomeStruct *p;
p = malloc(100*sizeof(SomeStruct)); /* without a cast */
return((void *)(p+1)); /* will the returned pointer point
to the 2nd...
|
by: desktop |
last post by:
I have read in Bjarne Stroustrup that using malloc and free should be
avoided in C++ because they deal with uninitialized memory and one
should instead use new and delete.
But why is that a...
|
by: raphfrk |
last post by:
I am having an issue with malloc and gcc. Is there something wrong
with my code or is this a compiler bug ?
I am running this program:
#include <stdio.h>
#include <stdlib.h>
typedef...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
