[Issue 4572] std.file.read return type (page 2)

August 04, 2010

[Issue 4572] std.file.read return type

Posted by Steven Schveighoffer
in reply to bearophile_hugs@eml.cc

Permalink

Steven Schveighoffer

Posted in reply to bearophile_hugs@eml.cc

Permalink

http://d.puremagic.com/issues/show_bug.cgi?id=4572



--- Comment #10 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-08-04 10:31:17 PDT ---
(In reply to comment #9)
> (In reply to comment #5)
> > any array operation which copies a block to another copies the flags from the original array block.  So the NO_SCAN flag should persist.  If it doesn't, that's a bug (looking at it, dup is the only function that doesn't copy the block attributes, I'll address this on the mailing list).
> 
> Concatenating arrays doesn't preserve the bit either.

Yes, that should be addressed too, thanks for pointing it out!

> And if the user allocates
> the void[], the NO_SCAN bit won't be set anyway. The user must remember to
> allocate a ubyte[] array to get it right. How many users will even understand
> why? (Also if you copy one array into another, flags won't be preserved.

You're splitting hairs here.  ubyte and void are both just as nebulous, it's just that void[] requires you to cast to something before reading it.  It means "I don't know what the type is."  ubyte means "this is an array of unsigned bytes", which is somewhat as nebulous, and one could argue more useful.  But wouldn't it be best to just ask for the type you wish?  What if you want to read a utf-8 file, wouldn't it be better for file.read() to return a char[]?  I think the template solution works best.

> If you
> allocate the void[] with C-malloc, lifetime.d won't do the right thing either.)

Who's allocating a void[] with c-malloc?  I thought std.file.read allocated the data with gc_malloc?

> Let me repeat: the only reason why you want to use void[] here is because void[] implicitly converts to any other array type.

Well, it's for consistency.  void[] does not implicitly convert to another array type, rather another array type can implicitly convert to void[].  So as far as returning void[], it forces you to cast, even if you expect the data to be ubyte[].

> But doing that is bogus anyway. If you convert it to an int[], you implicitly assume the data stored on the disk is in the same endian as your machine's. If it's an array of struct, you assume there are no padding issues (or further byte order issues). If it's a char[], you assume it's valid utf-8.

So?  Is one not allowed to assume the contents of a file are in a format they expect?  Typically one inserts magic numbers or something similar in a fie to ensure the file is correct, but I don't see why casting makes the user more keenly aware that the file might be incorrect.

> I think it's a good thing to remind the user of 2. by forcing him to explicitly cast the array. Yes, dear user, you ARE reinterpret casting your data to a bunch of bytes!

And that is what a void[] return does... not sure what you are getting at here.

> I guess Andrei will remove the usage of void[] anyway because of his beloved Java subset of D. void[] would allow aliasing pointers with integers, which is a no-no in SafeD.

hehe, I don't think you know how close Andrei and Java are.

> > But we can forgo all this stuff if we add a template parameter to read, so you can specify exactly the type you want.  If you know your file is a bunch of int's, you could do:
> > 
> > std.file.read!(int)();
> 
> I guess nothing can stop the devs from killing Phobos with even more template bloat. Your function call signature forgets anything about endians, though.

All it does is apply a type to a common function's return.  Endianness is an implementation issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4572



--- Comment #11 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-08-06 05:13:42 PDT ---
After discussion on the druntime mailing list, it was agreed that dup should preserve the bits, but we decided to leave concatenation as-is.  This shouldn't be a huge issue, because one doesn't often concatenate void[]s together. There's no clear choice in concatenation because multiple arrays are being concatenated together, and none of them is going to "own" the data afterwards.

So I think in light of dup now preserving the scan bit, the issue of using void[] as the return type of std.file.read (non-templated version) is moot.

But I still think being able to apply a type to the return data array via a template parameter would be a good enhancement.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Forums