Happy christmas

[jameskuyper]

Bart C wrote:
....

I'm used to text files using one of CR, LF or CRLF to terminate lines. I
have routines that read a line at a time and take care of this. And binary
mode means a 'getfilesize()' function is more accurate.

There are real, moderately popular systems in current use which have
conforming implementations of C, where files are record-based, and the
operating system keeps track of how much of each record is actually
used. On some of those systems, lines of text are padded to the end of
a record. They might be padded with '\0', or ' ', or even arbitrary
garbage - I don't know, and you shouldn't assume that you know either.
The operating system provides routines that allow you to determine
where the lines actually end, but the only way to determine this while
using exclusively the C standard library is to open the file in text
mode. Will your code work correctly on such a system, both for reading
and for writing?

 

[Flash Gordon]

army1987 wrote, On 27/12/07 14:01:

For files opened as text the format of the return of ftell can be totally
unrelated to the amount of memory needed.

For files opened in binary mode an fseek to SEED_END need not be
supported meaningfully. So the mode does not affect the fact that the
method used to find the size of the file is fundamentally broken. Using
text mode on text files, however, *does* have the benefit of correctly
handling end-of-line and the end of the text file (which is a character
that would be read in binary mode on some systems, such as Windows if
such a marker has been written).

 

[Flash Gordon]

Bart C wrote, On 27/12/07 13:23:

(I *never* use text mode, in fact I hardly remembered it existed until
reading your post; I use binary. What's the point?) [...]

If you use an OS such as Unix or Linux that uses a single '\n'
character to represent end-of-line in external files, then text and
binary mode will likely work the same way -- but then your software
might fail if you try to run it on a different system. Since text
mode costs you nothing (and saves having to type the extra 'b' in the
mode string), why not use it?

I'm used to text files using one of CR, LF or CRLF to terminate lines. I
have routines that read a line at a time and take care of this. And binary
mode means a 'getfilesize()' function is more accurate.

So it fails under VMS. Do you also correctly handle a ^Z in a text file
if I use a Windows program that appends one to indicate the end?

Writing the EOL chars properly for that OS so that other software can deal
with it might be a valid point. Although I would prefer my own control as to
what exactly is output.

OK, so you prefer to have to write code to handle the vagaries of every
implementation of interest. Just as long as you realise there can be a
lot more variety than you are currently aware of.

 

[Bart C]

Bart C wrote, On 27/12/07 13:23:

So it fails under VMS.

I don't even know what VMS is; something to do with IBM? I'm hardly likely
to have such a system as a hobbyist programmer in my front room. The
computers I can buy tend to have Windows. And years ago when I was selling
software my clients all had Windows too.

Do you also correctly handle a ^Z in a text file if I use a Windows
program that appends one to indicate the end?

If reading an entire file into memory, I append ETX and NUL to aid the
caller when scanning the data. A double ETX won't do any harm. The NUL turns
it into an ASCIIZ string (yes, I assume ASCII; the last non-ASCII machine I
used was in 1977).

OK, so you prefer to have to write code to handle the vagaries of every
implementation of interest. Just as long as you realise there can be a lot
more variety than you are currently aware of.

I tend to overlay my own API over the C runtime library. Then it's slightly
more immune to changes in the host OS. Although for some of us that's
unlikely to be anything other than Windows or Linux. Except perhaps code
running on servers? And perhaps embedded systems but that's a different
world anyway.

Bart

 

[Walter Roberson]

I don't even know what VMS is; something to do with IBM?

*Sigh*.

VMS is a multiuser operating system was first released by
Digital Equipment Corporation (DEC) in late 1977. It was widely
deployed in both scientific computing and business, and was one of
the key alternatives to IBM's operating systems (which tended
to look and feel like you were using a mainframe). It had a
very rich filesystem; even today, if you want to learn how
filesystems might have evolved quite differently (and better in many
cases), I would recommend reading about VMS.

I'm hardly likely
to have such a system as a hobbyist programmer in my front room.

Well, perhaps *you* are unlikely to have such a system, but there
are a number of hobbyist programmers who do have such systems at home.
You can get complete source at www.openvms.org .

The
computers I can buy tend to have Windows. And years ago when I was selling
software my clients all had Windows too.

Your words seem to imply that because -you- have only dealt with
Windows, that it is unimportant for people to write code that works
on other operating systems as well.

(yes, I assume ASCII; the last non-ASCII machine I
used was in 1977).

You said that you are using Windows. To the best of my recollection,
Windows has *never* been ASCII: I believe that even the very first
version of it used a an extension of ASCII. These days, Windows is
Unicode, primarily with UTF-8 or UTF-16 encoding.

 

[Flash Gordon]

Bart C wrote, On 27/12/07 20:48:

I don't even know what VMS is; something to do with IBM?

No, when I was using it it was from the Digital Electric Company (IIRC)
AKA DEC.

I'm hardly likely
to have such a system as a hobbyist programmer in my front room.

You can if you want.

The
computers I can buy tend to have Windows. And years ago when I was selling
software my clients all had Windows too.

Mine are Windows and/or *nix these days.

If reading an entire file into memory, I append ETX and NUL to aid the
caller when scanning the data. A double ETX won't do any harm.

This is the sort of thing that used to lead to text files slowly growing
as each load/save cycle added another ^Z.

The NUL turns
it into an ASCIIZ string (yes, I assume ASCII; the last non-ASCII machine I
used was in 1977).

For many this is a valid assumption. I have no objection to it when it
is known to be a limitation.

I tend to overlay my own API over the C runtime library. Then it's slightly
more immune to changes in the host OS.

This is indeed the "correct" way of dealing with system specifics and
providing a higher level API when appropriate.

Although for some of us that's
unlikely to be anything other than Windows or Linux. Except perhaps code
running on servers? And perhaps embedded systems but that's a different
world anyway.

For some the world is limited to a small subset of existing systems and
there is nothing wrong with this. You seem to know about the portability
limits you are placing on your code and decided that they are
acceptable. I see nothing wrong with this where, as seems to be the case
with you, you are *aware* that you are sacrificing some level of
portability for other benefits such as ease of coding.

I also agree that sometimes there are good reasons for treating text
files as binary, such as when your program has to deal with idiot lusers
who use the wrong method of transferring text files, as long as again it
is known that this limits the systems your code is portable to.

 

[Bart C]

*Sigh*.

VMS is a multiuser operating system was first released by
Digital Equipment Corporation (DEC) in late 1977. It was widely

I was using DEC around that time, but not VMS. It must have passed me by.
Maybe this was on a VAX which I never used. Not that I was that interested
in operating systems then.

Well, perhaps *you* are unlikely to have such a system, but there
are a number of hobbyist programmers who do have such systems at home.
You can get complete source at www.openvms.org .

I will have a look.

Your words seem to imply that because -you- have only dealt with
Windows, that it is unimportant for people to write code that works
on other operating systems as well.

The market for home and small business computers seemed to be dominated by
desktops and Windows. And that's why I wrote for Windows. If my clients all
had VMS maybe I would have written for that. But keeping cross-platform
capability in mind seemed less important if the product will run on just the
one OS. Especially with deadlines

You said that you are using Windows. To the best of my recollection,
Windows has *never* been ASCII: I believe that even the very first
version of it used a an extension of ASCII.

Well, the coding for characters 0 to 127 seemed remarkably close to ASCII!
128 to 255 was something called I think ANSI coding. It wasn't EBCDIC
anyway.

Bart

 

[Richard Heathfield]

Bart C said:

Well, the coding for characters 0 to 127 seemed remarkably close to
ASCII! 128 to 255 was something called I think ANSI coding. It wasn't
EBCDIC anyway.

To some extent, it depended on the software you were using. For example,
IBM's DisplayWrite word processor used an EBCDIC encoding, for mainframe
compatibility.

 

[Bart C]

Bart C wrote, On 27/12/07 20:48:

No, when I was using it it was from the Digital Electric Company (IIRC)
AKA DEC.

I recall it as Digital Equipment Corporation. If you're talking about VAX,
PDP-11 and the like.


Bart

 

[Flash Gordon]

Bart C wrote, On 27/12/07 22:52:

I recall it as Digital Equipment Corporation. If you're talking about VAX,
PDP-11 and the like.

Yes, the VAX, PDPs etc.

 

[Walter Roberson]

You can get complete source at www.openvms.org .

Checking further, I see I was incorrect about
the available download being complete source; it is only
a "Freeware CD". I was thinking of the wrong sense of "open"
in the name "OpenVMS".

 

[jameskuyper]

The market for home and small business computers seemed to be dominated by
desktops and Windows. And that's why I wrote for Windows. If my clients all
had VMS maybe I would have written for that. But keeping cross-platform
capability in mind seemed less important if the product will run on just the
one OS. Especially with deadlines

Most of the desktops where I work, and the only currently working
desktop machine at my home, runs Linux. The larger machines where I
work run Irix, and many of the other desktops are Macs running OS/X.
In my last job we did a lot of work on Solaris systems. Before that, I
worked on Unix and VMS machines.

It's a mistake to assume that the environment you're used to is the
only one of any significance. Keep in mind that the C standard is
intended to be efficiently implementable just about every where, not
just on the platform that dominates your part of the computing
universe. No matter which platform that is, most C implementations are
for some other kind of platform. If you want to use a language that
doesn't cater to the peculiarities of such a wide variety of machines,
than you shouldn't be using C, because that's fundamental to very
design philosophy of C.

 

[Dann Corbit]

Checking further, I see I was incorrect about
the available download being complete source; it is only
a "Freeware CD". I was thinking of the wrong sense of "open"
in the name "OpenVMS".

I don't have the context of the original post, but the OpenVMS operating
system source code listing used to come with the machine on microfilm. It
was originally all in assembly, but I guess that with later versions they
came to their senses and wrote it in a higher level language for the most
part. I have not looked at OS code for a long time.

 

[Bart C]

Most of the desktops where I work, and the only currently working
desktop machine at my home, runs Linux.
...OS/X...Solaris systems...Unix and VMS machines.

It's a mistake to assume that the environment you're used to is the
only one of any significance.

I finally have a Linux that has working internet. That and browsing this
newsgroup might help to broaden my outlook beyond Windows.

If you want to use a language that
doesn't cater to the peculiarities of such a wide variety of machines,
than you shouldn't be using C, because that's fundamental to very
design philosophy of C.

My little secret is I don't program in C much, only snippets. But I use the
C runtime so many discussions here are relevant.

Much of my work has been creating simple languages and writing compilers and
the like. C is important here for various reasons: it is simple and
transparent, and if an interface is defined in C then it's easy to work out
the mechanics. I don't think there's anything else quite like it. (Now if
they could fix that awful syntax...)

Bart

 

[Bob Doherty]

I don't have the context of the original post, but the OpenVMS operating
system source code listing used to come with the machine on microfilm.

Actually it was on microfiche

It
was originally all in assembly, but I guess that with later versions they
came to their senses and wrote it in a higher level language for the most
part. I have not looked at OS code for a long time.

VMS was never all in assembly. The most prevalent language was
Bliss32, a sort of structured assembly language. However, the VMS
team made almost a fetish of using nearly all of the supported
languages someplace in the VMS sources (Pascal, PL/1, C, Basic,
COBOL,Fortran,etc). One supposition for that behavior was that it was
to keep the 'suits' and bean counters from removing the run-time
libraries of any language from the distribution.

 

[CBFalconer]

.... snip ...

VMS was never all in assembly. The most prevalent language was
Bliss32, a sort of structured assembly language. However, the VMS
team made almost a fetish of using nearly all of the supported
languages someplace in the VMS sources (Pascal, PL/1, C, Basic,
COBOL,Fortran,etc). One supposition for that behavior was that
it was to keep the 'suits' and bean counters from removing the
run-time libraries of any language from the distribution.

Very nice. Too bad more systems didn't do this.