Bug 23770 - Volatile Pointers rejected by compiler
Summary: Volatile Pointers rejected by compiler
Alias: None
Product: Compilers
Classification: Mono
Component: C# ()
Version: unspecified
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Marek Safar
Depends on:
Reported: 2014-10-12 17:56 UTC by Paul
Modified: 2014-11-10 06:07 UTC (History)
1 user (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Paul 2014-10-12 17:56:34 UTC
Per Microsoft's documentation, (and compiles successfully in MSVC2010) a pointer in unsafe context is a valid volatile type.

But Mono's compiler rejects this with Error CS0677: "A volatile field cannot be of the type 'byte*'"; "A volatile field cannot be of the type 'int*'"

Example declaration (inside an unsafe project):
	volatile byte* begin;
	volatile int* head, tail;

This appears to originate in the CanBeVolatile() method in field.cs:

I'm hoping this is a small fix and that you just need to add an additional check for a pointer here?

Currently running the following version of MonoDevelop:
Xamarin Studio
Version 5.5 (build 227)
Installation UUID: 51e6b202-7a9b-4e3a-af9e-7c2cffb47d60
	Mono 3.10.0 ((detached/47db868)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 310000019

Although based on my link above this problem seems to exist in master right now. Thanks in advance!
Comment 1 Paul 2014-10-12 19:39:57 UTC
Is it possible that this somehow broke in Mono 3.10?
I downgraded to MRE 3.08 and now the code is building again.
Comment 2 Marek Safar 2014-11-10 06:07:55 UTC
Fixed in master and Mono 3.12