How to interface to a C struct with volatile variables?

[Charles Hixson]

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.