Reading ELF Files

[yazd via Digitalmars-d-learn]

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."