Author |
Topic: Line feeds & carriage returns in binary files (Read 674 times) |
|
HugoS
New Member
member is offline
Posts: 5
|
 |
Line feeds & carriage returns in binary files
« Thread started on: Sep 16th, 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.
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Line feeds & carriage returns in binary files
« Reply #1 on: Sep 16th, 2015, 03:04am » |
|
on Sep 16th, 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.
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender: 
Posts: 210
|
|
Re: Line feeds & carriage returns in binary files
« Reply #2 on: Sep 16th, 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.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Line feeds & carriage returns in binary files
« Reply #3 on: Sep 16th, 2015, 11:49am » |
|
on Sep 16th, 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.
|
|
|
|
HugoS
New Member
member is offline
Posts: 5
|
|
Re: Line feeds & carriage returns in binary files
« Reply #4 on: Sep 16th, 2015, 8:16pm » |
|
on Sep 16th, 2015, 11:49am, Richard Russell wrote: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. |
|
on Sep 16th, 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.
|
|
Logged
|
|
|
|
|
