www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - File I/O - rawWrite issues

reply "Carl" <myemail mysite.com> writes:
I am learning D so I thought this would be the correct place for 
this question (I assume I am making an error, not the compiler).

I am writing arrays of ubytes using rawWrite to a file. Whenever 
I write arrays full of numbers I have no problems, but once I 
write an array with zeroes I can then no longer write to that 
file.

For example:
ubyte[] data = [5, 34, 9, 45];
file.rawWrite(data); // OKAY

ubyte[] data = [0, 0, 0, 45];
file.rawWrite(data); // NOT OKAY


I get no errors or exceptions, it just won't write the array. I 
can't even open a new file stream and write, not even after 
rerunning the program. My only guess is some kind of string 
related problem where '\0' causes it to terminate.

Thanks in advance.



P.S. DMD, Ubuntu 11
May 08 2013
next sibling parent reply "Meta" <jared771 gmail.com> writes:
 For example:
 ubyte[] data = [5, 34, 9, 45];
 file.rawWrite(data); // OKAY

 ubyte[] data = [0, 0, 0, 45];
 file.rawWrite(data); // NOT OKAY


Since ubytes are pretty much the same as chars, I think writing 0 
to the file will actually write the null character, which 
probably isn't a good thing.
May 08 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/08/2013 02:46 PM, Meta wrote:


 For example:
 ubyte[] data = [5, 34, 9, 45];
 file.rawWrite(data); // OKAY

 ubyte[] data = [0, 0, 0, 45];
 file.rawWrite(data); // NOT OKAY


 Since ubytes are pretty much the same as chars,


True from the point of view of sizes: they are both 8-bit wide. However, 
they are different beasts: char is merely a UTF-8 code unit. ubyte does 
not have such a meaning attached to it.


 I think writing 0 to the
 file will actually write the null character, which probably isn't a good
 thing.


I don't see any problem there. rawWrite() should just write 0.

I think Carl should provide a short program that demonstrates the 
problem. :)

Ali
May 08 2013
parent reply "Carl" <myemail mysite.com> writes:
Wow, I feel silly.

In the process of making sample code I found the problem: I have 
been reading the output with a text editor instead of a hex 
editor. To think I spent hours on this problem... *face palm*

Thanks for your quick replies.
May 08 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 09, 2013 at 01:11:00AM +0200, Carl wrote:

 Wow, I feel silly.
 
 In the process of making sample code I found the problem: I have
 been reading the output with a text editor instead of a hex editor.
 To think I spent hours on this problem... *face palm*


[...]

No need to be embarrassed; it happens to the best of us. IME, some of
the most frustrating, hair-pulling bugs that take hours (or days!) to
get to the bottom of often turn out to be dead-easy trivial mistakes
that got overlooked because they were *too* obvious.

I remember an embarrassing occasion where I got so frustrated that the
compiler is adamantly producing wrong code when the source code is
*obviously* correct, that I reinstalled the entire GCC toolchain, C
library, the entire works, only to find that it *still* didn't help.
Finally I discovered that it had nothing to do with the compiler /
libraries at all. It was a trivial typo substituting , for ; in the
wrong place in my code, thus subtly changing its meaning while leaving
only a few pixels difference in the appearance of the source code. I
spent the better part of a day finding this problem. *sigh*

Or another occasion where I got so frustrated when a code change deep
inside some complicated algorithm mysteriously had no effect on the
output whatsoever, even after inserting printf's into the code and
verifying that the new code did actually get run. Many hair-pulling
hours later, I suddenly realized that I had been looking at the wrong
output file -- that containing stale output from an earlier test run
before the code change.  *face palm for 5 full minutes*.


T

-- 
Why do conspiracy theories always come from the same people??
May 08 2013
parent 1100110 <0b1100110 gmail.com> writes:
On 05/08/2013 07:29 PM, H. S. Teoh wrote:

=20
 No need to be embarrassed; it happens to the best of us. IME, some of
 the most frustrating, hair-pulling bugs that take hours (or days!) to
 get to the bottom of often turn out to be dead-easy trivial mistakes
 that got overlooked because they were *too* obvious.


+1

I'm not even going to mention the times that one simply forgets to
recompile...  Now _that's_ embarrassing.
May 15 2013
prev sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 8 May 2013 at 21:34:00 UTC, Carl wrote:

 I am learning D so I thought this would be the correct place 
 for this question (I assume I am making an error, not the 
 compiler).

 I am writing arrays of ubytes using rawWrite to a file. 
 Whenever I write arrays full of numbers I have no problems, but 
 once I write an array with zeroes I can then no longer write to 
 that file.

 For example:
 ubyte[] data = [5, 34, 9, 45];
 file.rawWrite(data); // OKAY

 ubyte[] data = [0, 0, 0, 45];
 file.rawWrite(data); // NOT OKAY


 I get no errors or exceptions, it just won't write the array. I 
 can't even open a new file stream and write, not even after 
 rerunning the program. My only guess is some kind of string 
 related problem where '\0' causes it to terminate.

 Thanks in advance.



 P.S. DMD, Ubuntu 11


Works fine on my Arch linux(64bit):

	import std.stdio;

	void main(){
		auto oFile = File("testfile","w");

		ubyte[] data1 = [0, 0, 0, 45];
		oFile.rawWrite(data1);

		ubyte[] data2 = [1, 2, 3, 4];
		oFile.rawWrite(data2);

		oFile.close();

		auto iFile = File("testfile","r");

		ubyte[16] buffer;

		writeln(iFile.rawRead(buffer));

		iFile.close();
	}

Prints: [0, 0, 0, 45, 1, 2, 3, 4]


If you were working on windows I would have suggested to try 
opening the file in binary mode.
May 08 2013