LB Booster: Line feeds & carriage returns in binary files

LB Booster
Programming >> Liberty BASIC language >> Line feeds & carriage returns in binary files
http://lbb.conforums.com/index.cgi?board=lblang&action=display&num=1442361784

Line feeds & carriage returns in binary files
Post by HugoS on Sep 16^th, 2015, 12:03am

When writing a file in binary mode three additional bytes 0D 0A 0A are appended to the file. So, the below code generates a file containing 4 bytes (01 0D 0A 0A) whereas the same code in LB generates a file containing a single byte - which is what I'd expect.

let a$ = chr$(1)
open "test.dat" for binary as #test
print #test, a$
close #test

Is there a way to suppress this?

Thanks.

Re: Line feeds & carriage returns in binary files
Post by Richard Russell on Sep 16^th, 2015, 03:04am

on Sep 16^th, 2015, 12:03am, HugoS wrote:

Is there a way to suppress this?

Please see item 12 in the Compatibility section of the LBB docs, which says this:

"Opening a file in BINARY mode does not prevent PRINT outputting a newline (CRLF). To suppress the newline add a trailing semicolon ; to the PRINT statement; this will not affect the operation of the program in LB4."

http://www.lbbooster.com/lbb.html#compatibility

Quote:

the same code in LB generates a file containing a single byte - which is what I'd expect.

I consider LB's behavior in this respect to be anomalous.

Richard.

Re: Line feeds & carriage returns in binary files
Post by tsh73 on Sep 16^th, 2015, 06:39am

HugoS,
for me your program creates file of 3 bytes
01 0D 0A

But. Opening file for binary does not overwrite it - may be 4th byte (0A) is leftover from previous runs?

Also. I was really surprised looking for a file on LBB directory - (probably I should remember) -
DefaultDir for me points to %TEMP%, so file created there.

Re: Line feeds & carriage returns in binary files
Post by Richard Russell on Sep 16^th, 2015, 11:49am

on Sep 16^th, 2015, 06:39am, tsh73 wrote:

Opening file for binary does not overwrite it - may be 4th byte (0A) is leftover from previous runs?

As you say, OPEN for BINARY does not truncate an existing file; if that is a problem you can instead use OPEN for OUTPUT (you can still write 'binary' data: there's not really any difference between a 'binary' file and a 'sequential' file).

That is the main reason why I do not like the fact that, in LB, opening a file in BINARY mode changes the behaviour of PRINT#. If you decide you want to truncate an existing file, so you alter BINARY to OUTPUT (or the opposite), the actual data written to the file may change!

So in LBB PRINT# is unaffected by the mode the file is opened in. If there is no trailing semicolon it appends a CRLF (chr$(13)+chr$(10)) to the data, if there is it doesn't. Fortunately LB is happy to have the semicolon (even with a file opened for BINARY) so it's easy to maintain compatibility.

I would have preferred OPEN for BINARY to be called something like OPEN for MODIFY, because the principal effect is to allow an existing file to be modified. Whether the contents of the file are 'binary' data or not is irrelevant.

Richard.

Re: Line feeds & carriage returns in binary files
Post by HugoS on Sep 16^th, 2015, 8:16pm

on Sep 16^th, 2015, 11:49am, Richard Russell wrote:

on Sep 16^th, 2015, 03:04am, Richard Russell wrote:

"Opening a file in BINARY mode does not prevent PRINT outputting a newline (CRLF). To suppress the newline add a trailing semicolon ; to the PRINT statement; this will not affect the operation of the program in LB4."

http://www.lbbooster.com/lbb.html#compatibility

I consider LB's behavior in this respect to be anomalous.

Richard.

Thanks Richard. I took LB's binary mode literally (I use it to create bitmap and TarGa image files) and was struggling to understand why a carriage return and line feed would appear in a 'binary' file. Your explanation makes sense though.