Malloc

[Chris Dollin]

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.

 

[Guest]

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:

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

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.


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

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

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.

 

[Nick Keighley]

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

 

[Dik T. Winter]

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

 

[Guest]

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]

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]

 

[Dik T. Winter]

> Dik T. Winter wrote: ....
>
> 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.

 

[Richard Tobin]

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

[/QUOTE]

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

 

[Guest]

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:

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>

 

[Francois Grieu]

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]

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]

 

[Charlton Wilbur]

RT> It may be a misunderstanding of the statement in the standard
RT> that "the order and contiguity of storage allocated by
RT> successive calls to the calloc, malloc and realloc functions
RT> is 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

 

[Old Wolf]

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]

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:[email protected]>

 

[Dave Thompson]

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