Malloc

[pavan]

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.

[Richard Heathfield]

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

You are slipping:

Yes, but in this case it was purely because I didn't read your original
article thoroughly enough.

>

>>From N869:

7.19 Input/output <stdio.h>

....which your code fragment did not include. That it was annotated as
being merely a fragment, not a complete program, was what had escaped
me.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Dave Vandervies]

In article <eq*********@news1.newsguy.com>,
Chris Torek <no****@torek.netwrote:

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

It would actually be a great improvement over the /bin/true found on
the system I'm posting this from.

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

How many of those "various reasons" are actually good reasons?

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

Most of such a beast, however, can be.

I don't remember the exact counts, but one time when this subject came
up I was just finishing up a module for the project I work on at my day
job in which something like 2% of what ended up getting left in our CVS
repository was system-specific code included in the final build. (Another
20%ish was test wrappers used to exercise the code on a completely[1]
different system (intended to be portable to any system with a conforming
hosted C implementation and an interactive command-line user interface,
but only actually used on one) and the remainder was portable standard
C used in both the deployment version and the offline test version.)
dave

[1] Well, same machine architecture, but the OSs between the code and
the processor were close to being as different as two x86 OSs can
possibly be.

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Biblethumper (n): Someone who ought to try opening it up and reading it
for comprehension for a change, already.
--Shamelessly Stolen From Anthony de Boer in the scary devil monastery

[Dave Vandervies]

In article <n6axh.973$6P4.592@trnddc06>,
Yevgen Muntyan <mu****************@tamu.eduwrote:

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

From there, it's not going too much farther to say that this is also a
C program, modulo any errors in my memory:
--------
import java.io.*;

class foo
{
public static void main(String[] args)
{
System.out.println("Hello, World!");
}
};
--------
(Proof: Fixing the errors introduced by me having recycled those neurons
produces a program that gcc will accept if installed suitably; and gcc
is a conforming C implementation; therefore, n869 section 4, paragraph
7 implies that this is a conforming C program.)

You can expand the definition of what qualifies as C as much as you like,
but that doesn't mean your expanded definition is useful.
(Question for the language lawyers: paragraph 5 defines strictly
conforming in a way that forbids "output dependent on any unspecified,
undefined, or implementation-defined behavior". Is this an exhaustive
list of differences between conforming implementations, or does there
exist a strictly conforming program that produces different output on
different implementations?)
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Biblethumper (n): Someone who ought to try opening it up and reading it
for comprehension for a change, already.
--Shamelessly Stolen From Anthony de Boer in the scary devil monastery

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Dave Vandervies wrote:

(Question for the language lawyers: paragraph 5 defines strictly
conforming in a way that forbids "output dependent on any unspecified,
undefined, or implementation-defined behavior". Is this an exhaustive
list of differences between conforming implementations, or does there
exist a strictly conforming program that produces different output on
different implementations?)

A program can be strictly conforming on one implementation and not on
another:
int array[30000];
int main(void) {}

Or a program can be strictly conforming on multiple (not all)
implementations with different effects:
#include <stdlib.h>
int main(void) {
system("echo off");
}

[CBFalconer]

santosh wrote:

Richard Tobin wrote:

>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 is STOOPID. I published one fragment showing a means of
handling use of binary or text input in the same program, and this
makes 10 articles with no connection to the original purpose.
Well, maybe the 10th has some connection.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"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

[Richard Bos]

"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <tr*****@gmail.comwrote:

Dave Vandervies wrote:

(Question for the language lawyers: paragraph 5 defines strictly
conforming in a way that forbids "output dependent on any unspecified,
undefined, or implementation-defined behavior". Is this an exhaustive
list of differences between conforming implementations, or does there
exist a strictly conforming program that produces different output on
different implementations?)

A program can be strictly conforming on one implementation and not on
another:

Not at all. This is the whole point of a strictly conforming program. A
SCP works, and works identically except for environment and input
differences, on _all_ implementations. It shall not exceed _any_
_minimum_ implementation limit. That's not any implementation limit,
that's any _minimum_ implementation limit.

Richard

[Richard Heathfield]

CBFalconer said:

<snip>

This is STOOPID. I published one fragment showing a means of
handling use of binary or text input in the same program, and this
makes 10 articles with no connection to the original purpose.

Welcome to Usenet. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Richard Bos wrote:

"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <tr*****@gmail.comwrote:

Dave Vandervies wrote:

(Question for the language lawyers: paragraph 5 defines strictly
conforming in a way that forbids "output dependent on any unspecified,
undefined, or implementation-defined behavior". Is this an exhaustive
list of differences between conforming implementations, or does there
exist a strictly conforming program that produces different output on
different implementations?)

A program can be strictly conforming on one implementation and not on
another:

[ int array[30000];
int main(void) {} ]

Not at all. This is the whole point of a strictly conforming program. A
SCP works, and works identically except for environment and input
differences, on _all_ implementations. It shall not exceed _any_
_minimum_ implementation limit. That's not any implementation limit,
that's any _minimum_ implementation limit.

Please re-read my code. Whether it exceeds the /minimum/
implementation limit of 65535 bytes in an object depends on the
implementation. It won't if sizeof(int) <= 2, and it will if
sizeof(int) 2.

[Richard Heathfield]

Richard Bos said:

"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <tr*****@gmail.comwrote:

>Dave Vandervies wrote:

(Question for the language lawyers: paragraph 5 defines strictly
conforming in a way that forbids "output dependent on any
unspecified,
undefined, or implementation-defined behavior". Is this an
exhaustive list of differences between conforming implementations,
or does there exist a strictly conforming program that produces
different output on different implementations?)

A program can be strictly conforming on one implementation and not on
another:

Not at all. This is the whole point of a strictly conforming program.
A SCP works, and works identically except for environment and input
differences, on _all_ implementations. It shall not exceed _any_
_minimum_ implementation limit. That's not any implementation limit,
that's any _minimum_ implementation limit.

Just perhapsing around here...

Is the following program strictly conforming? Decide first, then scroll
down past the spoiler space.

int main(int argc, char **argv)
{
int rc = 0;
if(argc 0)
{
rc = 1;
}
return 0;
}

Is that program strictly conforming?


that program strictly conformin


hat program strictly conformi


t program strictly confor


program strictly conf


ogram strictly co


ram strictly


m strict


stri


I presume you answered "yes", but it is at least plausible that it might
not be.

Consider a pathological but nevertheless conforming hosted
implementation with sizeof(int) = 65536.

The (or at least *a*) relevant minimum implementation limit is in
5.2.4.1 (for C99) - "65535 bytes in an object (in a hosted environment
only)." On such a system, it is impossible to define an int object in a
strictly conforming program, because to do so is to exceed this minimum
limit.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Kenneth Brody]

Richard Tobin wrote:

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

However, Unix (being a POSIX-compliant system) utilities are
probably written to be POSIX-compliant, and therefore would
be compatible to any C-plus-POSIX system

(And, as someone else noted, how would one be "aware of
directories" on systems which have no such concept of a
"directory" to begin with?)

Of course, POSIXness is OT for clc. Is there some Usenet group
along the lines of comp.lang.c.posix?

I happen to strive for POSIX-compliant as much as reasonably
possible. Of course, even within that there is a need to going
outside the standard for some functionality, such as full-screen
(text) I/O. (And those are limited to a few modules which wrap
the system-specific functions.)

[...]

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

CBFalconer wrote:

>
Cesar Rabak wrote:

Kenneth Brody escreveu:

[...]

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.

[...]

Technically, if you can't write a program "entirely in standard C",
then you can't write it in "standard C". You can write "most of the
O/S" using "standard C", but you can't write "the O/S" using "standard
C".

Yes, adding the "entirely" qualifier makes it explicit what you meant,
but it's not essential to include it.

As a parent of school-aged children...

"Did you do your homework" cannot be truthfully answered "yes" unless
you have done "all" of your homework, not just "most" of it. :-)

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

[Yevgen Muntyan]

Dave Vandervies wrote:

In article <n6axh.973$6P4.592@trnddc06>,
Yevgen Muntyan <mu****************@tamu.eduwrote:

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

From there, it's not going too much farther to say that this is also a
C program, modulo any errors in my memory:
--------
import java.io.*;

[snip]

Well, I believe it *is* too much. Let's take a look at this:

file foo.h
-----------
#define BAR 0
-----------

file main.c
-----------
#include "foo.h"
int main (void)
{
return BAR;
}
-----------

It's not strictly conforming (the "foo.h" is not from the
standard, therefore implementation is free to ban "foo.h" as a
header name or look for "foo.h" only in /nonexisting/folder or
whatever else it likes), but it *is* a C program.

I believe "strictly conforming" was invented exactly for
that, to make C standard actually work in real life, not
only for programs using only standard features. I.e.
standard exists not only to define what and how strictly
conforming programs do, but also to make programmers able
to use implementation-specific stuff in a well-defined
way without worrying about portability. E.g. in this foo.h
case a programmer can expect this program to work without
worrying that "return BAR;" line will in fact be translated
as "mama += papa;" and produce a compilation error.

You can expand the definition of what qualifies as C as much as you like,
but that doesn't mean your expanded definition is useful.

True. It's also true that bananas are not apples. Are you saying that my
examples are not C programs? If yes, then I wonder what language you are
using to write programs.

Best regards,
Yevgen

[Default User]

Richard Bos wrote:

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

Not online anywhere, it still has some features that are in work. I
changed the room data structure and corresponding file, and the "save"
function has not caught up.


Brian

[Christopher Layne]

Kenneth Brody wrote:

Of course, POSIXness is OT for clc. Is there some Usenet group
along the lines of comp.lang.c.posix?

I happen to strive for POSIX-compliant as much as reasonably
possible. Of course, even within that there is a need to going
outside the standard for some functionality, such as full-screen
(text) I/O. (And those are limited to a few modules which wrap
the system-specific functions.)

[...]

comp.unix.programmer. Come join us for a good time.

Aside from long established standards such as C89/90, I feel POSIX is the only
other standard worth striving for as well.

[Christopher Layne]

Richard Tobin wrote:

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

-- Richard

Absolutely - as referenced by it's definition of "concatenating files". I
typically treat cat as a pipeline source rather than a utility to look at
text files.

[Christopher Layne]

Flash Gordon wrote:

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.

That's just the thing. The goal is to get RID of the difference - not enable
it.

[Christopher Layne]

Richard Heathfield wrote:

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>

Default is "binary mode". The additional "b" suffix is a no-op. Text mode does
not exist.

http://en.wikipedia.org/wiki/Newline
^
Interesting in some of the history BTW.

[Keith Thompson]

Christopher Layne <cl****@com.anodizedwrites:

Flash Gordon wrote:

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.

That's just the thing. The goal is to get RID of the difference - not enable
it.

The goal (or a goal) of Unix is to get rid of the difference. One of
the many goals of C is to enable software to work on multiple systems,
which requires dealing with the difference.

Now if you're just copying a file from point A to point B, or from
stdin to stdout, it probably doesn't matter whether you treat is as
text or as binary, assuming that the input transformations are exactly
reversed by the output transformations. But even that's not always
the case; for example, some systems have an explicit end-of-file
marker for text files, and if you concatenate two input files into one
output file, the output needs to have only a single marker.

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

[Keith Thompson]

Christopher Layne <cl****@com.anodizedwrites:

Richard Heathfield wrote:

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>

Default is "binary mode". The additional "b" suffix is a no-op. Text
mode does not exist.

There is no default. "w", as the second argument to fopen(), creates
a text file. "wb" creates a binary file. (It happens that, on *some*
systems, including Unix, binary mode and text mode are functionally
equivalent.)

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

[Flash Gordon]

Keith Thompson wrote, On 05/02/07 21:58:

Christopher Layne <cl****@com.anodizedwrites:

>Flash Gordon wrote:

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

That's just the thing. The goal is to get RID of the difference - not enable
it.

Well, the cat command has lots of options that only make sense for text
files. The diff command on Linux has options to tell it explicitly if
files are binary or text, I'm sure other example could be found where
there is a difference in handling of "text" and "binary" files on Unix
like systems.

The goal (or a goal) of Unix is to get rid of the difference. One of
the many goals of C is to enable software to work on multiple systems,
which requires dealing with the difference.

Now if you're just copying a file from point A to point B, or from
stdin to stdout, it probably doesn't matter whether you treat is as
text or as binary, assuming that the input transformations are exactly
reversed by the output transformations. But even that's not always
the case; for example, some systems have an explicit end-of-file
marker for text files, and if you concatenate two input files into one
output file, the output needs to have only a single marker.

Indeed. However, none of this changes the earlier point that one can
sensibly implement a "cat" program, like various other useful utilities,
in standard C. Others, of course, like "find" require extensions.
--
Flash Gordon

[Christopher Layne]

Flash Gordon wrote:

Keith Thompson wrote, On 05/02/07 21:58:

>Christopher Layne <cl****@com.anodizedwrites:

>>Flash Gordon wrote:

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.
That's just the thing. The goal is to get RID of the difference - not
enable it.

Well, the cat command has lots of options that only make sense for text
files. The diff command on Linux has options to tell it explicitly if
files are binary or text, I'm sure other example could be found where
there is a difference in handling of "text" and "binary" files on Unix
like systems.

It does have options, correct. However, the baseline posix definition:

CAT(P)

NAME
cat - concatenate and print files

SYNOPSIS
cat [-u][file ...]

DESCRIPTION
The cat utility shall read files in sequence and shall
write their contents to the standard output in the same sequence.

OPTIONS
The cat utility shall conform to the Base Definitions volume of
IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.

The following option shall be supported:

-u Write bytes from the input file to the standard output without
delay as each is read.
--

That's pretty much it aside from implementation specific versions of cat.
There's really no way to tell cat "this is a text mode file and this is a
binary mode file" at a baseline posix level. Everything is binary - unless
cat is told to analyze the data and produce different output. Even then, it
won't consider CR-LF vs LF. There are additional non-posix options, but none
to handle text mode specifically (atleast in typical GNU/Solaris/etc. cat).
Additionally, to my knowledge, the "treat binary files as text" options are
to simply ignore the presence of a '\0' in the input stream and *not* to
preprocess "\r\n" or anything of that nature.

e.g.:
--binary-files=TYPE
If the first few bytes of a file indicate that the file
contains binary data, assume that the file is of type TYPE.
By default, TYPE is binary, and grep normally outputs either
a one-line message saying that a binary file matches, or no
message if there is no match. If TYPE is without-match, grep
assumes that a binary file does not match; this is equivalent to
the -I option. If TYPE is text, grep processes a binary file
as if it were text; this is equivalent to the -a option.
Warning: grep --binary-files=text might output binary garbage,
which can have nasty side effects if the output is a terminal
and if the terminal driver interprets some of it as com-
mands.

The rationale above is to prevent terminal mangling, not to handle any
dos-isms.

$ echo "microsoft is lame." ms_is_lame
$ hexdump ms_is_lame
0000000 696d 7263 736f 666f 2074 7369 6c20 6d61
0000010 2e65 000a
0000013
$ cat -A ms_is_lame
microsoft is lame.$
$ unix2dos ms_is_lame
unix2dos: converting file ms_is_lame to DOS format ...
$ hexdump ms_is_lame
0000000 696d 7263 736f 666f 2074 7369 6c20 6d61
0000010 2e65 0a0d
0000014
$ cat -A ms_is_lame
microsoft is lame.^M$
$

As you can see, cat will always see that '\r' as exactly what it is and of no
other significance. Had I not used -A (GNU cat specific), then cat would see
nothing of significance.

[Mark McIntyre]

On Sun, 04 Feb 2007 20:51:05 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:

>Mark McIntyre escreveu:

>On Sun, 04 Feb 2007 14:09:32 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:

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

No idea how you expect to see it, since you stupidly plonked me.
Still, if by some chance you are still listening, why not go look at
the source code for an OS?

>*PLONK*

As far as I can work out, you plonked me for not being able to
understand your english. Curious.
--
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

[Dik T. Winter]

In article <a0************@news.flash-gordon.me.ukFlash Gordon <sp**@flash-gordon.me.ukwrites:

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:

....

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.

There is quite some difference. On all systems there are calls to
'fopen' that will succeed. I know of systems where a 'file list
open' will always fail.

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?

....

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.

I know of systems where opening a binary file in text mode fails.

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.

Still the remaining question is: should it open the resource or the
data fork? All these things are pretty system specific, so using a
utility with Unix in mind may give pretty weird results on other
systems.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dik T. Winter]

In article <eq**********@pc-news.cogsci.ed.ac.ukri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <JC********@cwi.nl>, Dik T. Winter <Di********@cwi.nlwrote:

....

>

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

None of the languages I did encounter in the course of time.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dik T. Winter]

In article <61************@news.flash-gordon.me.ukFlash Gordon <sp**@flash-gordon.me.ukwrites:

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.

You might also want to be able to specify the resource or data fork.
That would make it even more widely portable.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Richard Tobin]

In article <JD********@cwi.nl>, Dik T. Winter <Di********@cwi.nlwrote:

Second, many languages *do* provide directory access as part of the
language (rather than an add-on like Posix).

>None of the languages I did encounter in the course of time.

Common Lisp is an example of one that attempted to provide a model
subsuming a wide range of operating systems.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Flash Gordon]

Christopher Layne wrote, On 05/02/07 23:21:

Flash Gordon wrote:

>Keith Thompson wrote, On 05/02/07 21:58:

>>Christopher Layne <cl****@com.anodizedwrites:
Flash Gordon wrote:

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.
That's just the thing. The goal is to get RID of the difference - not
enable it.

Well, the cat command has lots of options that only make sense for text
files. The diff command on Linux has options to tell it explicitly if
files are binary or text, I'm sure other example could be found where
there is a difference in handling of "text" and "binary" files on Unix
like systems.

It does have options, correct. However, the baseline posix definition:

CAT(P)

The AIX and Linux have options for line numbering and that is one of
several options that do not make sense for a binary file. Diff on the
systems I have access to has options to has explicit options for
specifying operation on text or binary files, and options such as
ignoring white space which only make sense on a text file.

That's pretty much it aside from implementation specific versions of cat.
There's really no way to tell cat "this is a text mode file and this is a
binary mode file" at a baseline posix level. Everything is binary - unless

<snip>

Taking your attitude to an extreme it makes perfect sense to use cat to
look at a file containing a JPEG, after all there is no difference
between a binary file and a text file since everything is binary.
However, we all know that a graphics viewer would be more useful if you
want to see the picture.

As you can see, cat will always see that '\r' as exactly what it is and of no
other significance. Had I not used -A (GNU cat specific), then cat would see
nothing of significance.

I am fully aware that on Unix there is no translation of /n. However,
you still seem to be completely failing to miss (or are ignoring) my
main point which is that a "cat" program can be written in completely
standard C and the additional point that in such an implementation it
makes sense to provide an option so specify whether it is processing
text or binary files so that on systems where there *is* a difference,
for example DOS, Windows, MacOS 9 an earlier, VMS etc you can still get
appropriate behaviour for the normal usage of cat on either text or
binary files. I have never claimed that the options would cause a change
of behaviour on Unix like systems, but it would not stop it from being
usable on Unix like systems.
--
Flash Gordon

[Christopher Layne]

Flash Gordon wrote:

I am fully aware that on Unix there is no translation of /n. However,
you still seem to be completely failing to miss (or are ignoring) my
main point which is that a "cat" program can be written in completely
standard C and the additional point that in such an implementation it
makes sense to provide an option so specify whether it is processing
text or binary files so that on systems where there *is* a difference,
for example DOS, Windows, MacOS 9 an earlier, VMS etc you can still get
appropriate behaviour for the normal usage of cat on either text or
binary files. I have never claimed that the options would cause a change
of behaviour on Unix like systems, but it would not stop it from being
usable on Unix like systems.

....And my point is that by doing so, you enable the continuance of crappy
standards to exist. You will notice that there is NO BUILT IN method or flag
to convert DOS->Unix on any of the typical text processing commands in Unix -
unless a provider of such went out of their way to make it so. The only
outlier here is DOS and Windows. Everyone else is doing it sanely and not
making special ammends for what a text file or binary file even are.

Numbering lines and/or interpreting binary as "text" is just manipulation of
the safety logic for a program that *typically* handles files *without nul
bytes or other control character data contained within them* such that they
won't spew a bunch of control data at you. That's it.

It doesn't make an application more compliant just because it supports some
archaic bad choice of delimiting lines. It merely allows it so support said
archaic standard. The longterm goal is to separate the distinction
between "text file" and "binary file" by weeding out the sources of it.

$ cat /bin/ls | egrep FILEs
Binary file (standard input) matches

The language of "binary file" above actually means "input containing a nul
byte, and this means it probably contains control characters which will screw
up your terminal - therefore we will not output the matched lines."

$ cat /bin/ls | tr -d '\0' | egrep FILEs
List information about the FILEs (the current directory by default).

[Keith Thompson]

Christopher Layne <cl****@com.anodizedwrites:

Flash Gordon wrote:

I am fully aware that on Unix there is no translation of /n. However,
you still seem to be completely failing to miss (or are ignoring) my
main point which is that a "cat" program can be written in completely
standard C and the additional point that in such an implementation it
makes sense to provide an option so specify whether it is processing
text or binary files so that on systems where there *is* a difference,
for example DOS, Windows, MacOS 9 an earlier, VMS etc you can still get
appropriate behaviour for the normal usage of cat on either text or
binary files. I have never claimed that the options would cause a change
of behaviour on Unix like systems, but it would not stop it from being
usable on Unix like systems.

...And my point is that by doing so, you enable the continuance of crappy
standards to exist. You will notice that there is NO BUILT IN method or flag
to convert DOS->Unix on any of the typical text processing commands in Unix -
unless a provider of such went out of their way to make it so. The only
outlier here is DOS and Windows. Everyone else is doing it sanely and not
making special ammends for what a text file or binary file even are.

There are more things in Heaven and Earth, Horatio ...

You say that "everyone else" doesn't distinguish between binary and
text files. Are you familiar with any such systems that *aren't*
derived from or directly modeled on Unix?

VMS has record-oriented files. I don't know exactly how VMS
represents a text file, but it's definitely different from a binary
file (of which there are many distinct types).

IBM mainframe operating systems tend to represent text files as
sequences of fixed-length records, each record representing a line.
(This representation goes back to decks of punch cards.)

I'm sure there are many other examples.

Numbering lines and/or interpreting binary as "text" is just manipulation of
the safety logic for a program that *typically* handles files *without nul
bytes or other control character data contained within them* such that they
won't spew a bunch of control data at you. That's it.

It doesn't make an application more compliant just because it supports some
archaic bad choice of delimiting lines. It merely allows it so support said
archaic standard. The longterm goal is to separate the distinction
between "text file" and "binary file" by weeding out the sources of it.

Perhaps that's *your* long term goal. By all means feel free to
advocate it, but please do so somewhere else. It's not a goal of the
C language, which is designed to work with a variety of underlying
systems.

[...]

Personally, I happen to like the way Unix treats text and binary
files, but it's not the only way to do it, and it's absolutely not the
business of the C language to impose that design choice. If it did
so, the result would be that C would not be supported on systems that
make a distinction text and binary files.

Think about it. What real advantage do you gain by treating text and
binary files alike? Sure, it's more flexible, but that flexibility
does come at a cost. Try seeking to the 10000th line of a text file
in constant time. Try determining *reliably* whether a file contains
text or binary data.

Here's something I just tried:

% gcc c.c -o c.c
c.c: In function 'main':
c.c:2: warning: return type of 'main' is not 'int'
% cat c.c

Since I typed "-o c.c" rather than "-o c", the compiler wrote the
executable file over my source file. The "cat" program just assumed
that "c.c" was a text file, and displayed it for me. In a system that
distinguishes file types, I would have gotten a nice error message
like "cat: File c.c is not text" rather than a screenful of garbage.

Distinguishing between text and binary files at the file system level
is similar to distinguishing between, say, integer and real variables
in a program. You could have a language that doesn't make such a
distinction, and just applies different operators for integer addition
and floating-point addition -- and if you apply the wrong operator,
that's just too bad. (In fact, I think one of C's ancestors did this.
BCPL? B?) But the advantages of enforcing the distinction are so
great, and the advantages of allowing the distinction to be ignored
are so slight, that even C (sometimes incorrect viewed as a low-level
assembler) enforces the distinction.

It's not obvious that the same reasoning that leads to strictly typed
variables applies equally to strictly typed files, and as I said above
I like the decision the designers of Unix made. But it's not the only
sensible decision.

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

[CBFalconer]

Christopher Layne wrote:

Flash Gordon wrote:

>I am fully aware that on Unix there is no translation of /n.
However, you still seem to be completely failing to miss (or are
ignoring) my main point which is that a "cat" program can be
written in completely standard C and the additional point that in
such an implementation it makes sense to provide an option so
specify whether it is processing text or binary files so that on
systems where there *is* a difference, for example DOS, Windows,
MacOS 9 an earlier, VMS etc you can still get appropriate
behaviour for the normal usage of cat on either text or binary
files. I have never claimed that the options would cause a change
of behaviour on Unix like systems, but it would not stop it from
being usable on Unix like systems.

...And my point is that by doing so, you enable the continuance of
crappy standards to exist. You will notice that there is NO BUILT
IN method or flag to convert DOS->Unix on any of the typical text
processing commands in Unix - unless a provider of such went out
of their way to make it so. The only outlier here is DOS and
Windows. Everyone else is doing it sanely and not making special
ammends for what a text file or binary file even are.

And you are ignoring the fact that all the world is not Unix, just
as all the world is not an x86. There are many file systems. Many
of them do not have the concept of a line ending character, or
sequence. Yet they are perfectly capable of running properly
composed C programs. One very common version is the card image,
where each line consists of precisely 80 chars, with short lines
blank padded on the rear.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"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

[Chris Dollin]

Keith Thompson wrote:

Distinguishing between text and binary files at the file system level
is similar to distinguishing between, say, integer and real variables
in a program. You could have a language that doesn't make such a
distinction, and just applies different operators for integer addition
and floating-point addition -- and if you apply the wrong operator,
that's just too bad. (In fact, I think one of C's ancestors did this.
BCPL? B?)

Later versions of BCPL did. (Don't know if B did or not.) Actually,
earlier ones did too, if you squint a little: after all, you can
call any value, and if it isn't a function, tough.

--
Chris "electric hedgehog" Dollin
"We did not have time to find out everything we wanted to know."
- James Blish, /A Clash of Cymbals/

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Chris Dollin wrote:

Keith Thompson wrote:

Distinguishing between text and binary files at the file system level
is similar to distinguishing between, say, integer and real variables
in a program. You could have a language that doesn't make such a
distinction, and just applies different operators for integer addition
and floating-point addition -- and if you apply the wrong operator,
that's just too bad. (In fact, I think one of C's ancestors did this.
BCPL? B?)

Later versions of BCPL did. (Don't know if B did or not.) Actually,
earlier ones did too, if you squint a little: after all, you can
call any value, and if it isn't a function, tough.

According to <http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html>, B
didn't support floating point variables.

[Flash Gordon]

Dik T. Winter wrote, On 06/02/07 00:24:

In article <a0************@news.flash-gordon.me.ukFlash Gordon <sp**@flash-gordon.me.ukwrites:

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:

...

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.

There is quite some difference. On all systems there are calls to
'fopen' that will succeed. I know of systems where a 'file list
open' will always fail.

<shrugIn that case it always fails.

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?

...

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.

I know of systems where opening a binary file in text mode fails.

So it fails. I don't have a problem with that.

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.

Still the remaining question is: should it open the resource or the
data fork? All these things are pretty system specific, so using a
utility with Unix in mind may give pretty weird results on other
systems.

Well, since C does not have any support for data/resource forks it would
obviously only deal with whichever that C implementation uses when you
do an fopen. I.e. you have exactly the same problem as any program
written in C on such an implementation and you would take the same
route. This might make it less useful that it could otherwise be, but it
would still work for any file that a standard C program can work on. So
unless you are saying you cannot open *any* file without using some
non-standard method to specify which fork the program would still work,
just with some limitations.

Having said that, if I was writing the implementation, I would seriously
consider some kind of syntax on the file name to allow you to specify
which fork, but I'm not writing the implementation so you are stuck with
whatever the implementation provides.

Also note that I am not saying everything can be written in standard C
nor that there are not sometimes advantages to using non-standard
extensions, just that some useful things can be and they will work, even
if with some limitations, on (in this case hosted) C implementations.
--
Flash Gordon

[Nick Keighley]

On 3 Feb, 16:10, "pavan" <[e-mail]:

malloc() does not make any guarantees regarding the contiguity of
memory.

you are the second person in a few days to say this. It is not true.
What is the source of your information so that it can be corrected
(if
possible).
--
Nick Keighley

[Dik T. Winter]

In article <11*************@news-west.ncl****@com.anodized writes:
....

...And my point is that by doing so, you enable the continuance of crappy
standards to exist. You will notice that there is NO BUILT IN method or flag
to convert DOS->Unix on any of the typical text processing commands in Unix -
unless a provider of such went out of their way to make it so. The only
outlier here is DOS and Windows. Everyone else is doing it sanely and not
making special ammends for what a text file or binary file even are.

And MacOS 9 and earlier. (But that is also not compatible with DOS and
Windows.)
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Dik T. Winter wrote:

In article <11*************@news-west.ncl****@com.anodized writes:
...

...And my point is that by doing so, you enable the continuance of crappy
standards to exist. You will notice that there is NO BUILT IN method or flag
to convert DOS->Unix on any of the typical text processing commands in Unix -
unless a provider of such went out of their way to make it so. The only
outlier here is DOS and Windows. Everyone else is doing it sanely and not
making special ammends for what a text file or binary file even are.

And MacOS 9 and earlier. (But that is also not compatible with DOS and
Windows.)

IIRC, MacOS 9 and below used ASCII with CR as the newline character,
but made no distinction between text and binary mode.

[Clark S. Cox III]

Harald van Dijk wrote:

Dik T. Winter wrote:

>In article <11*************@news-west.ncl****@com.anodized writes:
...

> ...And my point is that by doing so, you enable the continuance of crappy
standards to exist. You will notice that there is NO BUILT IN method or flag
to convert DOS->Unix on any of the typical text processing commands in Unix -
unless a provider of such went out of their way to make it so. The only
outlier here is DOS and Windows. Everyone else is doing it sanely and not
making special ammends for what a text file or binary file even are.

And MacOS 9 and earlier. (But that is also not compatible with DOS and
Windows.)

IIRC, MacOS 9 and below used ASCII with CR as the newline character,
but made no distinction between text and binary mode.

[OT]
There was a distinction. In most C implementations on the old MacOS. In
binary mode, '\n' produced 0x0A, while '\r' produced 0x0D. In text mode
the two were reversed (i.e. \n <-0x0D, \r <-0x0A).
[/OT]

--
Clark S. Cox III
cl*******@gmail.com

[Richard Tobin]

In article <11**********************@l53g2000cwa.googlegroups .com>,
Nick Keighley <ni******************@hotmail.comwrote:

>malloc() does not make any guarantees regarding the contiguity of
memory.

>you are the second person in a few days to say this. It is not true.
What is the source of your information so that it can be corrected

It may be a misunderstanding of the statement in the standard that
"the order and contiguity of storage allocated by successive calls to
the calloc, malloc and realloc functions is unspecified".

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Dik T. Winter]

In article <11**********************@a75g2000cwd.googlegroups .com"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <tr*****@gmail.comwrites:

Dik T. Winter wrote:

....

And MacOS 9 and earlier. (But that is also not compatible with DOS and
Windows.)

IIRC, MacOS 9 and below used ASCII with CR as the newline character,
but made no distinction between text and binary mode.

Indeed. But copying a file requires more than a simple implementation of
cat.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Clark S. Cox III wrote:

Harald van Dijk wrote:

Dik T. Winter wrote:

In article <11*************@news-west.ncl****@com.anodized writes:
...
...And my point is that by doing so, you enable the continuance of crappy
standards to exist. You will notice that there is NO BUILT IN method or flag
to convert DOS->Unix on any of the typical text processing commandsin Unix -
unless a provider of such went out of their way to make it so. The only
outlier here is DOS and Windows. Everyone else is doing it sanely and not
making special ammends for what a text file or binary file even are.

And MacOS 9 and earlier. (But that is also not compatible with DOS and
Windows.)

IIRC, MacOS 9 and below used ASCII with CR as the newline character,
but made no distinction between text and binary mode.

[OT]
There was a distinction. In most C implementations on the old MacOS. In
binary mode, '\n' produced 0x0A, while '\r' produced 0x0D. In text mode
the two were reversed (i.e. \n <-0x0D, \r <-0x0A).
[/OT]

Ah, thanks for the correction.

[Flash Gordon]

Clark S. Cox III wrote, On 06/02/07 13:29:

Harald van Dijk wrote:

>Dik T. Winter wrote:

>>In article <11*************@news-west.ncl****@com.anodized writes:
...
...And my point is that by doing so, you enable the continuance of crappy
standards to exist. You will notice that there is NO BUILT IN method or flag
to convert DOS->Unix on any of the typical text processing commands in Unix -
unless a provider of such went out of their way to make it so. The only
outlier here is DOS and Windows. Everyone else is doing it sanely and not
making special ammends for what a text file or binary file even are.

And MacOS 9 and earlier. (But that is also not compatible with DOS and
Windows.)

IIRC, MacOS 9 and below used ASCII with CR as the newline character,
but made no distinction between text and binary mode.

[OT]
There was a distinction. In most C implementations on the old MacOS. In
binary mode, '\n' produced 0x0A, while '\r' produced 0x0D. In text mode
the two were reversed (i.e. \n <-0x0D, \r <-0x0A).
[/OT]

<On topic>
I.e. the C implementations conformed to the C standard.
</On topic>

<OT>
Amusingly (well, amusing to me) the FTP specification says to use CRLF
as line termination when transferring files in ASCII mode, the preferred
mode for transferring text files according to the standard.
</OT>
--
Flash Gordon

[Francois Grieu]

In article <12*************@corp.supernews.com>,
"Clark S. Cox III" <cl*******@gmail.comwrote:

Harald van Dijk wrote:

IIRC, MacOS 9 and below used ASCII with CR as the newline character,
but made no distinction between text and binary mode.

[OT]
There was a distinction. In most C implementations on the old MacOS. In
binary mode, '\n' produced 0x0A, while '\r' produced 0x0D. In text mode
the two were reversed (i.e. \n <-0x0D, \r <-0x0A).
[/OT]

[OT]
Well, I'm not using "most C", but Apple's MrC under MPW, when I program
for MacOS 9 (which I guess you include in "the old MacOS", thought from
some standpoint MacOS 9 is the least ancient MacOS, and OS X is a new
OS having little resemblance with MacOS; not even the name, or the
way eacute or EOL are encoded).

Anyway, under this environment, binary and text files are identical.
The compiler allways translates '\n' to 13 and '\r' to 10.
(no I did not get these in reverse). This is perfectly conformant
(if not usual), and cause little problem in practice.
[/OT]

Francois Grieu

[Clark S. Cox III]

Francois Grieu wrote:

In article <12*************@corp.supernews.com>,
"Clark S. Cox III" <cl*******@gmail.comwrote:

>Harald van Dijk wrote:

>>IIRC, MacOS 9 and below used ASCII with CR as the newline character,
but made no distinction between text and binary mode.

[OT]
There was a distinction. In most C implementations on the old MacOS. In
binary mode, '\n' produced 0x0A, while '\r' produced 0x0D. In text mode
the two were reversed (i.e. \n <-0x0D, \r <-0x0A).
[/OT]

[OT]
Well, I'm not using "most C", but Apple's MrC under MPW, when I program
for MacOS 9 (which I guess you include in "the old MacOS", thought from
some standpoint MacOS 9 is the least ancient MacOS, and OS X is a new
OS having little resemblance with MacOS; not even the name, or the
way eacute or EOL are encoded).

Anyway, under this environment, binary and text files are identical.
The compiler allways translates '\n' to 13 and '\r' to 10.
(no I did not get these in reverse). This is perfectly conformant
(if not usual), and cause little problem in practice.
[/OT]

[OT]
MPW was precisely why I didn't say "all". IIRC, Metrowerks and Think C
both defaulted to the behavior that I described above, but had options
to behave in the MPW-like fashion.
[/OT]

--
Clark S. Cox III
cl*******@gmail.com

[Charlton Wilbur]

>>>>"RT" == Richard Tobin <ri*****@cogsci.ed.ac.ukwrites:

>you are the second person in a few days to say this. It is not
true. What is the source of your information so that it can be
corrected

RTIt may be a misunderstanding of the statement in the standard
RTthat "the order and contiguity of storage allocated by
RTsuccessive calls to the calloc, malloc and realloc functions
RTis unspecified".
In other words, in the code fragment

char *foo = malloc(10);
char *bar = malloc(10);

you cannot conclude that foo[10] == bar[0]. (Even if both calls can
be shown to be successful.)

This is a reasonable thing to point out to novice programmers.

Charlton


--
Charlton Wilbur
cw*****@chromatico.net

[Old Wolf]

On Feb 7, 12:45 am, "Nick Keighley" <[e-mail]>
wrote:

On 3 Feb, 16:10, "pavan" <[e-mail]:

malloc() does not make any guarantees regarding the contiguity of
memory.

you are the second person in a few days to say this. It is not true.
What is the source of your information so that it can be corrected

He might be meaning that the memory returned by malloc need
not be contiguous at the physical level (or maybe not even at the
operating system level, for a virtual OS).

[Kenneth Brody]

Old Wolf wrote:

>
On Feb 7, 12:45 am, "Nick Keighley" <[e-mail]>
wrote:

On 3 Feb, 16:10, "pavan" <[e-mail]:

malloc() does not make any guarantees regarding the contiguity of
memory.

you are the second person in a few days to say this. It is not true.
What is the source of your information so that it can be corrected

He might be meaning that the memory returned by malloc need
not be contiguous at the physical level (or maybe not even at the
operating system level, for a virtual OS).

But, given that explanation, neither is this:

char text[] = "This text may not be in contiguous physical memory";

or even:

double d = 1.5;

So, why the sudden influx of "malloc doesn't guarantee contiguity"
questions?

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

[Dave Thompson]

On 6 Feb 2007 00:43:48 GMT, ri*****@cogsci.ed.ac.uk (Richard Tobin)
wrote:

In article <JD********@cwi.nl>, Dik T. Winter <Di********@cwi.nlwrote:

Second, many languages *do* provide directory access as part of the
language (rather than an add-on like Posix).

None of the languages I did encounter in the course of time.

Common Lisp is an example of one that attempted to provide a model
subsuming a wide range of operating systems.

.... for enumeration of and access to (ordinary) files, but not
directories as such (i.e. chairs in themselves <G>) or even links.

I know MUMPS had an external persistent hierarchical datastore
functionally like a typical Unixoid filesystem, but I never got close
enough to know if it was actually implemented that way.

- formerly david.thompson1 || achar(64) || worldnet.att.net