Greetings

I tried to initialize a struct member with a function pointer, and found that DMD2 did not like it. Are not function pointers compile time constants? And why they should not be?

Regards
- Cherry

On 20/02/2011 14:59, d coder wrote:
> Greetings
>
> I tried to initialize a struct member with a function pointer, and
> found that DMD2 did not like it. Are not function pointers compile
> time constants? And why they should not be?
>
> Regards
> - Cherry

No a function doesn't have an address until the .exe is loaded into memory. And with Address space randomisation on 'doze there is no reasonable way to make a function pointer a compile time value.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

Thanks Simon.

"Simon" <s.d.hammett@gmail.com> wrote in message news:ijrdif$1nn6$1@digitalmars.com...
> On 20/02/2011 14:59, d coder wrote:
>> Greetings
>>
>> I tried to initialize a struct member with a function pointer, and found that DMD2 did not like it. Are not function pointers compile time constants? And why they should not be?
>>
>> Regards
>> - Cherry
>
> No a function doesn't have an address until the .exe is loaded into memory. And with Address space randomisation on 'doze there is no reasonable way to make a function pointer a compile time value.
>

I didn't know Windows did that, I thought it was just certain versions of Unix/Linux. Do you happen to know which version of Windows was first to have it?

On Sun, 20 Feb 2011 16:23:14 -0500, Nick Sabalausky <a@a.a> wrote:

> "Simon" <s.d.hammett@gmail.com> wrote in message
> news:ijrdif$1nn6$1@digitalmars.com...
>> On 20/02/2011 14:59, d coder wrote:
>>> Greetings
>>>
>>> I tried to initialize a struct member with a function pointer, and
>>> found that DMD2 did not like it. Are not function pointers compile
>>> time constants? And why they should not be?
>>>
>>> Regards
>>> - Cherry
>>
>> No a function doesn't have an address until the .exe is loaded into
>> memory. And with Address space randomisation on 'doze there is no
>> reasonable way to make a function pointer a compile time value.
>>
>
> I didn't know Windows did that, I thought it was just certain versions of
> Unix/Linux. Do you happen to know which version of Windows was first to have
> it?

Probably the first one with dlls?  I don't see how else you could have dlls, because you can't just say "this function will always be at address 12345, and no other function anyone else ever compiles can take that spot".

That being said, I'm not sure why the OP's issue couldn't be solved -- clearly position independent code works (and that is statically created), why couldn't a reference to that function also be created in a struct initializer?  Is it a limitation of the linker?

-Steve

On 21/02/2011 00:24, Steven Schveighoffer wrote:
> On Sun, 20 Feb 2011 16:23:14 -0500, Nick Sabalausky <a@a.a> wrote:
>
>> "Simon" <s.d.hammett@gmail.com> wrote in message
>> news:ijrdif$1nn6$1@digitalmars.com...
>>> On 20/02/2011 14:59, d coder wrote:
>>>> Greetings
>>>>
>>>> I tried to initialize a struct member with a function pointer, and
>>>> found that DMD2 did not like it. Are not function pointers compile
>>>> time constants? And why they should not be?
>>>>
>>>> Regards
>>>> - Cherry
>>>
>>> No a function doesn't have an address until the .exe is loaded into
>>> memory. And with Address space randomisation on 'doze there is no
>>> reasonable way to make a function pointer a compile time value.
>>>
>>
>> I didn't know Windows did that, I thought it was just certain versions of
>> Unix/Linux. Do you happen to know which version of Windows was first
>> to have
>> it?
>
> Probably the first one with dlls? I don't see how else you could have
> dlls, because you can't just say "this function will always be at
> address 12345, and no other function anyone else ever compiles can take
> that spot".

Vista. For any particular exe, you'll find that it's dependant dlls alway get loaded in the same place. That's why buffer overflow bugs (where/are) so easy to exploit.

>
> That being said, I'm not sure why the OP's issue couldn't be solved --
> clearly position independent code works (and that is statically
> created), why couldn't a reference to that function also be created in a
> struct initializer? Is it a limitation of the linker?
>
> -Steve

You can't use the relative jump of POS code.
The offset to the function will be different at each call site.

You could make function pointers compile time constants if:

You disallow ASR
You disallow them when compiling to a dll
You disallow in-lining of any function of which you take the address
You disallow the linker from rearranging functions
You disallow the linker from merging duplicate functions.
You merge the compiler and linker

And it wouldn't work with template functions anyway as you can get multiple copies of those.

That's a lot of stuff to give up.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

Simon Wrote:

> You could make function pointers compile time constants if:
> 
> You disallow ASR
> You disallow them when compiling to a dll
> You disallow in-lining of any function of which you take the address
> You disallow the linker from rearranging functions
> You disallow the linker from merging duplicate functions.
> You merge the compiler and linker

Interestingly, this data layout is impossible without rearranging:

byte a;
byte[&c] b;
byte c;

d coder <dlang.coder@gmail.com> writes:

> Greetings
>
> I tried to initialize a struct member with a function pointer, and found that DMD2 did not like it. Are not function pointers compile time constants? And why they should not be?
>
> Regards
> - Cherry

I just want to point out that this *should* be doable in D.  At compile time the function's address in the object code is a placeholder that the linker or loader will fixup based on the function symbol.  This is what linkers do!  And if an function ptr is used, the function can still be inlined; just need to keep around the real function reference through the pointer.

Dan