On Friday, 2 May 2014 at 15:25:55 UTC, Nordlöw wrote:
On Friday, 2 May 2014 at 10:42:40 UTC, yazd wrote:
On Thursday, 1 May 2014 at 17:31:52 UTC, Nordlöw wrote:
Here you go, https://github.com/yazd/elf-d.
Thanks!
Anytime. By the way, if you need more stuff out of it or help,
post an issue on github. I think I'll be able to help a bit
more. But if this library is to move forward, the API will
need a redesign. You might want to keep that in mind.
Ok. Great!
Some reflections:
- This is not a robust way of detecting limitations of the
package (elf.d):
static assert(is(size_t == ulong), "only 64bit is supported
for now");
This static assert needs to be called at run-time on the header
contents of the mmapped file itself.
- It is nice that you use MMFile. I do that too in my engine.
However, to make cooperation more flexible and efficient class
ELF should provide a ctor that takes and existing MMfile as
argument (refernce) during construction, since my file engine
class RegFile temporarily creates such instances when neeeded.
BTW: What does package keyword mean in the line
package MmFile file;
inside the definition of ELF.
For detail see for example:
https://github.com/nordlow/justd/blob/master/fs.d#L1192
You're correct in terms of the check. Anyway, I have just pushed
some changes to support both 32bit and 64bit elf binary files.
That required minor changes in the API, but it should still be
easy.
And I've added a constructor that takes an MmFile.
`package` here is a protection attribute. From the documentation
on dlang.org, " Package extends private so that package members
can be accessed from code in other modules that are in the same
package. This applies to the innermost package only, if a module
is in nested packages."