Reading ELF Files
yazd via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Sun May 4 11:11:44 PDT 2014
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."
More information about the Digitalmars-d-learn
mailing list