printig effort

[Ben Bacarisse]

C's text mode is already giving me problems by being too clever:

I'm using a language superimposed on C's runtime, which generates CR,LF for
new lines. This seems to get translated, when writing to STDOUT, to
CR,CR,LF, which on the screen looks the same. But sent to a file (using
Windows' >), these lines cause my (15yo) editor to crash.

It is not C being too clever, it the programmer not being clever
enough. If, in Windows, you are writing \r\n to a file, then one can
assume that you don't want to treat it as test file. If you do, it
will go wrong. You have two options:

(1) Treat your output as a binary stream. The downside is that you
will be putting \r\n into files even when your program is ported to a
system that prefers not to have these as line endings.

(2) If your output is text, treat it as text. Write the output in the
portable way C expects you to and the output will have the correct
line endings. The advantage you get is a simpler program that is
portable to other systems.

If your program is intended to generate output for use on "other"
systems, then (1) is the only way to go (and you need some way to tell
you program what sort of line ending to write). You will also not be
able to write to stdout[1]. If you are writing text files for use
"here" then (2) is the way to go.

Some programs need to do both, and then they have to know the mode of
each stream and the target line ending they must use for those stream
that are binary. Taking that a bit further, you might also need to
know the character encoding that the foreign system expects. Such
programs were quite common when truly diverse systems were more common.

Writing \r\n to a text stream is very unlikely to be the right thing
to do. Equally, not using text mode when writing text for the local
system just sounds like cutting your nose off to spite your face.

[1] There is often a system-specific way to re-open stdout in the mode
of your choice, so this is not a hard and fast rule.

 

[Keith Thompson]

So? I've used CP/M and I've dealt with files with it, text and binary,
without using C and it's 'text mode'. I don't recall any problems. I think
text files expected to have byte 0x1A as an end-of-text-file marker.

He said "CP/M 1". I'm not familiar with it, but apparently an early
version of CP/M used this fixed-length record representation for text
files.

I've considered up to now that C's notion of a text file is just a binary
file which uses a delimiter sequence D between 'lines' and a terminator
sequence E, for example:

abcdefDghDDijklDEmn

contains 4 lines "abcdef","gh","","ijkl".

With C's text mode simply translating D to and from it's version of \n for
this host and stopping at, or inserting, the E marker.

You were mistaken.

That's reasonable (except if it doesn't recognise D of an imported file, I
might as well make my own attempt at translation -- we all know the
possibilities for D are likely to be cr, crlf, lf, lfcr.).

Perhaps on the system you've used (though I've never heard of a system
that uses lfcr).

For text files not to be openable in binary mode, it would have to
do something really weird, like store each line of the file in a
separate hidden file, or in compressed form. But this I don't
believe; such goings-on would surely be hidden behind a translation
layer.

You don't have to believe it -- but it's perfectly true.

That translation layer, in C is called "text mode". If you choose
not to use it for some reason, you don't get its benefits.

The C standard says very little about how text files are actually
represented, or what you'll get if you read a text file in binary
mode. It doesn't even say anything specific about line endings;
that's just a special case of the more general translation. Take a
look at C99 7.19.2.

C's text mode is already giving me problems by being too clever:

I'm using a language superimposed on C's runtime, which generates CR,LF for
new lines. This seems to get translated, when writing to STDOUT, to
CR,CR,LF, which on the screen looks the same. But sent to a file (using
Windows' >), these lines cause my (15yo) editor to crash.

So don't write '\r' to a text file (unless you really want a '\r'
character in your text file).

If you're dealing with native text files, use text mode. There's no
good reason not to.

If you have to deal with non-native text files, things become more
difficult. You have to know the foreign format. Depending on the
system, you might be able to use native text mode with some tweaks
(such as explicitly adding a '\r' to each line, or ignoring it on
input), or you might have to use binary mode. If it's practical, it's
better to use a separate tool to convert text files to native format
(but that's not always practical).

 

[Harald van Dijk]

Maybe you could explain?

When you replied you did include the fwrite call.

He was indeed trying to check for an error but unsurprisingly Bill did
not read the manual and realise to check for 0 or a short count.

Exactly, he was trying to check, but checking whether fwrite(...) == EOF
does not actually check if fwrite fails.

 

[Bill Cunningham]

There's a wonderful thing called the internet. On it you will find

something called the world wide web and then Google. Try it.

Already tried. I learned a little. Not really enough I think to do much
good.

Bill

 

[concerned c.l.c reader]

Richard wrote (for the 1000th time):

USE A DEBUGGER AND LOOK AT THE VALUES.

Are you by any chance related with Jeff Relf? You seem to be the
only person on usenet who shares his obsession with debuggers.

For the 1000th time of asking. That or give up.

You are not going to cry, are you?

 

[santosh]

Richard wrote (for the 1000th time):


Are you by any chance related with Jeff Relf? You seem to be the
only person on usenet who shares his obsession with debuggers.


You are not going to cry, are you?

And I wonder whose sockpuppet this one is?