www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to interface to a C struct with volatile variables?

reply Charles Hixson <charleshixsn earthlink.net> writes:
Does D have an equivalent to the C marking of volatile?

Currently I'm just going to try removing all variables from the struct, 
as it's never declared in D or accessed from within D, and I just want 
to avoid cast(void*)s, but I may need to access something like this 
sometime in the future.
Feb 15 2013
parent reply Ben Davis <entheh cantab.net> writes:
On 16/02/2013 03:54, Charles Hixson wrote:

 Does D have an equivalent to the C marking of volatile?

 Currently I'm just going to try removing all variables from the struct,
 as it's never declared in D or accessed from within D, and I just want
 to avoid cast(void*)s, but I may need to access something like this
 sometime in the future.


In your case, I think you can declare opaque structs in D:

struct S;	//Opaque
struct S { ... }	//Not opaque

As for 'volatile', there's some info at 
http://dlang.org/deprecate.html#volatile about how it used to be 
available for marking statements as 'do not optimise field accesses'. 
The corrective action listed there is to use 'synchronized' instead. So 
probably your best bet is to use 'synchronized' blocks wherever you 
access the variables that you know are meant to be volatile.

Hope that helps :)
Feb 16 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-16 15:13, Ben Davis wrote:

 On 16/02/2013 03:54, Charles Hixson wrote:

 Does D have an equivalent to the C marking of volatile?

 Currently I'm just going to try removing all variables from the struct,
 as it's never declared in D or accessed from within D, and I just want
 to avoid cast(void*)s, but I may need to access something like this
 sometime in the future.


 In your case, I think you can declare opaque structs in D:

 struct S;    //Opaque
 struct S { ... }    //Not opaque

 As for 'volatile', there's some info at
 http://dlang.org/deprecate.html#volatile about how it used to be
 available for marking statements as 'do not optimise field accesses'.
 The corrective action listed there is to use 'synchronized' instead. So
 probably your best bet is to use 'synchronized' blocks wherever you
 access the variables that you know are meant to be volatile.

 Hope that helps :)


If you're interfacing with C you should just remove the volatile 
statement/keyword.

"There is no volatile type modifier in D. To declare a C function that 
uses volatile, just drop the keyword from the declaration."

http://dlang.org/interfaceToC.html

-- 
/Jacob Carlborg
Feb 16 2013
parent reply Ben Davis <entheh cantab.net> writes:
On 16/02/2013 15:19, Jacob Carlborg wrote:

 On 2013-02-16 15:13, Ben Davis wrote:

 As for 'volatile', there's some info at
 http://dlang.org/deprecate.html#volatile about how it used to be
 available for marking statements as 'do not optimise field accesses'.
 The corrective action listed there is to use 'synchronized' instead. So
 probably your best bet is to use 'synchronized' blocks wherever you
 access the variables that you know are meant to be volatile.

 Hope that helps :)


 If you're interfacing with C you should just remove the volatile
 statement/keyword.

 "There is no volatile type modifier in D. To declare a C function that
 uses volatile, just drop the keyword from the declaration."

 http://dlang.org/interfaceToC.html


That's only telling you how to declare a C *function*, not a C struct 
(or global). While you'll probably get away with it in practice, I think 
dropping it from a struct is technically unsafe (and may break as a 
result of future compiler optimisation improvements) unless you back it 
up with the 'synchronized' strategy.

I was going to suggest __gshared, but for struct members it implies 
static, so it's not what you want. There doesn't seem to be a way to 
make a struct member 'volatile' for the purposes of interacting with C 
(which seems to be a gap in the C support).
Feb 16 2013
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
On 02/16/2013 08:16 AM, Ben Davis wrote:

 On 16/02/2013 15:19, Jacob Carlborg wrote:

 On 2013-02-16 15:13, Ben Davis wrote:

 As for 'volatile', there's some info at
 http://dlang.org/deprecate.html#volatile about how it used to be
 available for marking statements as 'do not optimise field accesses'.
 The corrective action listed there is to use 'synchronized' instead. So
 probably your best bet is to use 'synchronized' blocks wherever you
 access the variables that you know are meant to be volatile.

 Hope that helps :)


 If you're interfacing with C you should just remove the volatile
 statement/keyword.

 "There is no volatile type modifier in D. To declare a C function that
 uses volatile, just drop the keyword from the declaration."

 http://dlang.org/interfaceToC.html


 That's only telling you how to declare a C *function*, not a C struct
 (or global). While you'll probably get away with it in practice, I think
 dropping it from a struct is technically unsafe (and may break as a
 result of future compiler optimisation improvements) unless you back it
 up with the 'synchronized' strategy.

 I was going to suggest __gshared, but for struct members it implies
 static, so it's not what you want. There doesn't seem to be a way to
 make a struct member 'volatile' for the purposes of interacting with C
 (which seems to be a gap in the C support).


Thank you.  Since "volatile", IIUC, is suppose to mean "This think can 
change without warning, and for no reason that you'll be able to see.", 
I think perhaps I should just use a normal variable of the correct size, 
and comment it as "/**< DON'T USE THIS VARIABLE*/".  My only qualm about 
this was that the compiler might write the current value of
the structure back over the structure parameter.  (Well, actually since 
I don't intend to use ANY of the variables in the struct, but just pass 
it to another C routine in the same library, the opaque pointer solution 
works well in THIS case.  But I was worried about what to do if I needed 
to change one of the variables.)

Perhaps this is worrying unreasonably...it's definitely worrying about 
things I don't yet need to deal with.
Feb 17 2013
parent Lee Braiden <leebraid gmail.com> writes:
On Sun, 17 Feb 2013 10:58:57 -0800, Charles Hixson wrote:

 Thank you.  Since "volatile", IIUC, is suppose to mean "This think can
 change without warning, and for no reason that you'll be able to see.",


It ALSO means, "This can be read by other processes / devices at any 
time, so don't assume you can ignore whatever I put in there, just 
because I don't use it later myself."

I think it was Walter who said that D just doesn't do this kind of 
volatility awareness, and the only way to achieve it in D is to write 
your code with inline assembly. That seems like a shame, to me.


 I think perhaps I should just use a normal variable of the correct size,
 and comment it as "/**< DON'T USE THIS VARIABLE*/".  My only qualm about
 this was that the compiler might write the current value of the
 structure back over the structure parameter.  (Well, actually since I
 don't intend to use ANY of the variables in the struct, but just pass it
 to another C routine in the same library, the opaque pointer solution
 works well in THIS case.  But I was worried about what to do if I needed
 to change one of the variables.)
 
 Perhaps this is worrying unreasonably...it's definitely worrying about
 things I don't yet need to deal with.


These sound like valid concerns.  Maybe D's contracts will help you to 
guarantee that nothing's being changed, though?


-- 
Lee
Feb 23 2013