[SOLVED] A question about opening binary files

rtmistler · 02-10-2021, 03:10 PM

Quote:

Originally Posted by jsbjsb001

TMy point: It's just not helpful to me to say "just look at the ASCII table", or "just read the man page", it just doesn't help. I'm not trying to be rude, a smartass or difficult, it's just the way I learn things. Not your fault in any way, but it is what it is, and there's nothing I can do about that.

Just wish to point out that the advice was not in the form of "just read". It cited the relevant parts of it and discussed their details as well as much more information beyond the reference.

You've solved this, all set.

ntubski · 02-10-2021, 05:24 PM

Quote:

Originally Posted by GazL

Looking at it again, I think he meant to say "newline characters", but even then as written the statement wouldn't be correct for writes.

Quote:

carriage return/line feed character pairs are converted to newline characters when they are read from a text file

IMO this still has the problem that you're using two different names ("line feed" and "newline") to refer to the same character value (10).

GazL · 02-10-2021, 06:59 PM

Quote:

Originally Posted by ntubski

IMO this still has the problem that you're using two different names ("line feed" and "newline") to refer to the same character value (10).

Yes, that occurred to me also, but I'm not responsible for the duality of ascii 0x0A as both LF or '\n' depending on context. It was already like that when I got here!

So, even though LF and '\n' are essentially the same character, it's IMO reasonable/correct to express it as:

On input CR+LF is converted to '\n' (new line)
On output '\n' (new line) is converted to CR+LF.

Using LF in place of either of those '\n' just feels wrong to me. YMMV.

jsbjsb001 · 02-11-2021, 03:30 AM

Quote:

Originally Posted by rtmistler

Just wish to point out that the advice was not in the form of "just read". It cited the relevant parts of it and discussed their details as well as much more information beyond the reference.

You've solved this, all set.

I apologize for giving that impression - it wasn't intended in any way. My point was that, just reading stuff isn't the best way of learning for me. I didn't intend to imply that you were just telling me to go and read XXXX. Again, I apologize for implying that.

I do appreciate your time, help and advice RT. It's just very frustrating for me when I try and read about something that I want to understand but cannot make any sense of it no matter what else I read, and how hard I try. I'm not blaming yourself for any of that, and I never would do that. But again, and in any case, I appreciate you taking the time to help, and I'm sure what you added in your post about the subject of binary will come in useful at some point. So thank you for your help

hazel · 02-11-2021, 05:37 AM

You can't understand this particular paragraph because, as GazL says, it is badly and confusingly written by the original author. But several posts in this thread have explained what the author probably intended to say, so that should solve your problem.

rnturn · 02-11-2021, 09:34 AM

Quote:

Originally Posted by michaelk

History 101...

The original term "return or carriage return character (CR)" was taken from the mechanical typewriter when you physically had to use a lever to move the paper carriage back to start of the line. The first press of the lever moved the carriage back to the beginning of the line and a second press advanced the paper to the next line (LF). With advanced electronic typewriters the mechanical levers were replaced by the "Return" or "enter" key as we know it today on computer keyboards.

Indeed. (Though on a manual typewriter, the lever does the line feed before the carriage return so the lever actually implemented a LF/CR.) Those of us who learned computing back in its Cretacious Age, Sending a "typical" file with CR/LF line termination to the line printer would result in:

Code:

Line 1
Line 2
Line 3
...

If a friend sent you a file from their UNIX system and you printed it, you more likely than not see:

Code:

Line 1
      Line 2
            Line 3
                  ...

until the text got to the right-hand edge of the paper and the rest of the text was lost though, usually, interpreting the newlines and, potentially, spitting out numerous blank pages. You can sometimes simulate this fun today by accidentally printing "program" instead of "program.log".

rtmistler · 02-11-2021, 10:01 AM

I think Programming in C Third Edition author just wrote unclear and inadvisable details:

Quote:

Under operating systems such as Windows, which distinguish text files from binary files, a b must be added to the end of the mode string to read or write a binary file. If you forget to do this, you will get strange results, even though your program will still run.

Very clear and correct.

Quote:

This is because on these systems, carriage return/line feed character pairs are converted to return characters when they are read from or written to text files. Furthermore, on input, a file that contains a Ctrl+Z character causes an end-of-file condition if the file was not opened as a binary file.

The distinction they may have considered to explain here is that a binary file can contain "any" data values, because it is binary. Whereas text files use certain data values to control how the output appears. So as a result, if you open a binary file and incorrectly try to interpret the contents as text, you'll run into problems, or as they did say "get strange results".

The next quote:

Quote:

There are times when this does matter. If I recall correctly Windows will translate \n to \r\n automagically unless you specify binary mode. I can't remember the exact order of events to tickle this situation but if you expect to produce accurate cross-platform content binary mode is one step you want to take.

This does not appear to have been written by the author Stephen Kochan, but instead from an anonymous poster, L7Sqr, years prior. (Now that I've visited the link). It is their opinion, it has bearing and relevance, but in the interest of wording and also clarity, the use of a term "automagically" is inadvisable, it is not a word. Fine, people sort of understand what it means, however it is not really talking about binary file open mode, instead the statement is talking about Unix/Linux vs DOS file formats. Once again, it has little bearing on the question and I feel something like that is polluting the entire understanding here.

If you can bridge the gap of understanding to realize that line terminator differences for text files has no bearing at all for binary versus text files, you'll be far closer to the point.

And to continue with that referred link, there's another poster who said things well, mike_2000_17:

Quote:

The binary mode is a legacy feature for a time when some computers had different memory encoding for binary versus text data. This distinction hasn't been relevant on any platform for a long time (probably 20-30 years), as far as I know. I guess you can still apply the "b" flag whenever you're opening a binary file (or intend to write binary data to a file), just to be pedantic, but it makes no difference in practice.

I think the original first statements from Programming in C Third Edition, has correct information, and the follow-up explanation could've been written in clearer form.

Geist · 02-18-2021, 06:07 AM

Hmm, I hve only skimmed this thread, but the moment you go into binary files, nothing truly matters unless you're following some sort of standard.
Binary is just raw bytes strung up as a big sequence, they have no inherent rhyme or reason and it's up to the programmer to assign meaning to it.

If you are converting from binary to text, you , as a programmer, could define that the byte sequence of FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAAFFFFFFFFFFFFFFFFFF0101010101FEFEDEADDEAD
means "a" in ascii.
or that a terabyte worths of zeros means "carriage return"/"newline".