Alex J Lennon | 31 Oct 08:20 2014

Cygwin build - warnings about arguments gint32 vs LONG


There seem to be a large number of warnings generated during the Windows/Cygwin build relating to the type of arguments provided to various support functions.

The functions seem to be mostly prototyped in platform includes such as


The warnings are of this flavour

/usr/i686-pc-mingw32/sys-root/mingw/include/winbase.h:1796:24: note: expected ‘PDWORD’ but argument is of type ‘guint32 *’

I have been experimenting with declaring some of the prototypes within the build environment instead of in those platform incldues but there's so much of this I am at a bit of a loss as to how to proceed.

I am now wondering if it is better to pull in winbase.h / winsock2.h and rewrite them to take the gint* style. I'm not terribly keen on that idea.

That or maybe there's a way to make gint32 and friends appear as LONG and the equivalents and so forth, although that also seems less than ideal.

Can anybody advise on a sensible way for me to approach this?




Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178 landline: +44 (0)1513 241374

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.

Mono-devel-list mailing list
Mono-devel-list <at>
Alexander Köplinger | 30 Oct 21:46 2014

PR 1081: Allow CLR binaries to be passed to Process.Start

This PR ( has been sitting in the queue for some time.  <at> kumpera
already gave his +1 to the patch, so I think we could merge it?

-- Alex 		 	   		  
Justin Clark-Casey | 30 Oct 21:26 2014

In Mono 3.2.8 but not with Microsoft .NET Framework 4 can bind to same UDP port twice by default

Hi folks.  In at least Mono 3.2.8 (3.2.8+dfsg-4ubuntu1), by default one can bind multiple UDP sockets to the
same port 
without error.  Under at least Microsoft .NET Framework 4 on Windows, the following error is generated instead

Unhandled Exception: System.Net.Sockets.SocketException: Only one usage of each
socket address (protocol/network address/port) is normally permitted
    at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress
    at System.Net.Sockets.Socket.Bind(EndPoint localEP)
    at UdpSamePort.Main(String[] args)

This gist [1] has a small program demonstrating this behaviour.  Explicitly setting
SocketOptionName.ReuseAddress to 
false on the socket prevents Mono from binding the second socket to the same address.

Is this expected behaviour for Mono (Linux?) compared to Windows?  I haven't checked this behaviour yet
under later (or 
earlier) Mono versions.




Justin Clark-Casey (justincc)
OSVW Consulting
Rodrigo Kumpera | 30 Oct 18:57 2014

Fwd: [eglib] Warning: assertion function returning

Forgot to CC dev

---------- Forwarded message ----------
From: Rodrigo Kumpera <kumpera <at>>
Date: Thu, Oct 30, 2014 at 1:57 PM
Subject: Re: [Mono-dev] [eglib] Warning: assertion function returning
To: Alex J Lennon <ajlennon <at>>

On Thu, Oct 30, 2014 at 12:34 PM, Alex J Lennon <ajlennon <at>> wrote:
Hi Rodrigo,

On 30/10/2014 17:28, Rodrigo Kumpera wrote:
Since the noreturn behavior is not verifiable by the compiler (it's part of the API contract) we can a hack to silence the warning.

If that's what's wanted that's fine by me of course. Easily done.

But I don't understand: Surely the fact the compiler is complaining shows that it does know that the function is returning, when it has been told via the attributing that the function should not?

As a test, if I add a while(1); at the bottom of the function then the complaint goes away as the compiler knows that the return is unreachable.

I am guessing I am misunderstanding your point?

More importantly, should the assertion handler return or not... ?

The problem is that the abort happens through the logging callback and that can't be verified by the compiler.

Any well behaved implementation must make sure it does not return. I think adding a while (1); at the end is a good enough solution.
We want the noreturn semantics there.

Mono-devel-list mailing list
Mono-devel-list <at>
Alexander Köplinger | 30 Oct 17:49 2014

Re: PR #1337 Review

Thanks for looking into it!

Date: Thu, 30 Oct 2014 11:47:01 -0500
Subject: Re: [Mono-dev] PR #1337 Review
From: ryan.melena <at>
To: alex.koeplinger <at>

Turns out the IEnumerable<object> vs ArrayList issue was likely caused by an error in our initial Deserialize(string, Type) method implementation that we misdiagnosed as an issue with using ArrayList.  Working on a pull request to revert the ArrayList / List<object> changes to JavaScriptSerializer.cs file.

Also found the source of the new unit test failure (an issue with our newest Deserialize(string, Type) method implementation) and will include a fix for that in the next pull request as well.
Mono-devel-list mailing list
Mono-devel-list <at>
Alex J Lennon | 30 Oct 17:08 2014

[eglib] Warning: assertion function returning


I'm seeing an eglib warning about an assertion handling function with a
G_GNUC_NORETURN attribute that is returning.

goutput.c: In function ‘monoeg_assertion_message’:
goutput.c:135:1: warning: ‘noreturn’ function does return [enabled by

I'm wondering how this should be resolved, ie. whether this function
should block, whether the attribute should be removed, or "something else"?

If the assertion handler should block then is while(1); sensible, or a
very bad idea?


Maury Markowitz | 30 Oct 15:05 2014

Understanding ZipSharp and Native(Un)Zip - any MonoPosixHelper gurus?

I'm hoping someone familiar with MonoPosixHelper and/or WindowsBase will see this.

I am attempting to port System.IO.Package to iOS. I have made some progress, to the point where my somewhat
stripped-down WindowsBase is compiling under Xamarin on the Mac, and I can run the Packaging functions to
the point of decompressing the file.

Following through the code, this appears to ultimately fail on this:

       [DllImport ("MonoPosixHelper", CallingConvention=CallingConvention.Cdecl)]
       static extern int unzOpenCurrentFile2 (UnzipHandle handle,
                                              out int method,
                                              out int level,
                                              int raw);

Looking over MonoPosixHelper, it *appears* this consists largely of Zlib. Zlib is already installed on
Mac/iOS in /usr/lib. So, in theory, P/Invoke should work given a few tweaks to the DllImport.

However, I cannot find any function called "unzOpenCurrentFile2" in MonoPosixHelper. I found some sort
of mapping in WindowBase's IOFunctions.cs, but I'm not sure I understand it's purpose, nor if it is in any
way related to this.

I can't shake the feeling that simply changing that DllImport is all I need, but I am too confused by the
naming to be sure. Any pointers would be greatly appreciated!

p.s. My apologies if this double-posts, I got some sort of bounce message.
Alexander Köplinger | 30 Oct 14:43 2014

Re: PR #1337 Review

You can run "make check FIXTURE=System.Web.Script.Serialization.JavaScriptSerializerTest" in mcs/class/System.Web.Extensions to only run the tests that are now failing.

As for ArrayList vs List<object>: can you add a unit test that verifies this?
-- Alex
Date: Thu, 30 Oct 2014 08:38:27 -0500
Subject: Re: [Mono-dev] PR #1337 Review
From: ryan.melena <at>
To: alex.koeplinger <at>
CC: miguel <at>; mono-devel-list <at>

I can take a look at the unit test problems but any help is appreciated.  I originally ran 'make check' and everything passed so I'm guessing these tests must not have been part of that script.

The change from ArrayList to List<object> is crucial because calling MS code assumes that the final result is an IEnumerable<object> (which an ArrayList is not).  It could conceivably be some other IEnumerable other than a List but I doubt that would fix the unit test issues.

On Thu, Oct 30, 2014 at 8:23 AM, Alexander Köplinger <alex.koeplinger <at>> wrote:
Hey, this breaks a few tests:
MonoTests.System.Web.Script.Serialization.JavaScriptSerializerTest.DeserializeDictionaryOfArrayList MonoTests.System.Web.Script.Serialization.JavaScriptSerializerTest.DeserializeObject MonoTests.System.Web.Script.Serialization.JavaScriptSerializerTest.InfinityAndNaN MonoTests.System.Web.Script.Serialization.JavaScriptSerializerTest.TestDeserialize MonoTests.System.Web.Script.Serialization.JavaScriptSerializerTest.TestDeserializeConverter1 MonoTests.System.Web.Script.Serialization.JavaScriptSerializerTest.TestDeserializeNonGenericOverload MonoTests.System.Web.Script.Serialization.JavaScriptSerializerTest.TestDeserializeTypeResolver MonoTests.System.Web.Script.Serialization.JavaScriptSerializerTest.TestSerialize1
The TestDeserializeNonGenericOverload is a new one added by the PR (it passes on MS.NET though, so we should make it work on Mono).
I'm not sure the switch from ArrayList to List<object> is correct, if I change that back all tests pass again except the new TestDeserializeNonGenericOverload.
-- Alex

From: miguel <at>
Date: Wed, 29 Oct 2014 15:02:39 -0400
To: Ryan.Melena+Mono-Devel-List <at>
CC: mono-devel-list <at>
Subject: Re: [Mono-dev] PR #1337 Review

Thanks for pointing this out.



On Wed, Oct 29, 2014 at 2:52 PM, RyanMelenaNoesis <Ryan.Melena+Mono-Devel-List <at>> wrote:
It was requested that I notify the mailing list about this pull request ( ) in order to facilitate conversation.  The changes were implemented to support JWT authentication in our web application and required a couple changes to existing Mono code.  The changes to existing code were necessary to make Mono compatible with MS calling code and are explained in line comments.  Please let me know if anyone has particular concerns with this pull request.

Mono-devel-list mailing list
Mono-devel-list <at>

_______________________________________________ Mono-devel-list mailing list Mono-devel-list <at>

Mono-devel-list mailing list
Mono-devel-list <at>
Eberhard Beilharz | 30 Oct 08:28 2014

PR #960: [MWF] Partially implement Help.ShowHelp

The change in PR #960 partially implements the ability to show a help
file by calling chmsee or whatever the environment variable
MONO_HELP_VIEWER is set to. This is still a partial implementation in
that it probably only works on Linux, but at least IMO it's an
improvement over the existing do-nothing implementation.

This change increases the compatibility with Windows by allowing to use
the same chm file and help calling code in the application on both
Windows and Linux. While this might not be optimal and it might be
better to use a more native format on Linux it allows to port a Windows
application more quickly to Linux.

Eberhard Beilharz | 29 Oct 23:06 2014

PR944 - Improve COM error handling


To revive one of my old pull requests: #944 implements some missing
pieces related to COM error handling. Namely it sets the error info in
GetHRForException() and converts the HRESULT values to managed exceptions.

RyanMelenaNoesis | 29 Oct 19:52 2014

PR #1337 Review

It was requested that I notify the mailing list about this pull request ( ) in order to facilitate conversation.  The changes were implemented to support JWT authentication in our web application and required a couple changes to existing Mono code.  The changes to existing code were necessary to make Mono compatible with MS calling code and are explained in line comments.  Please let me know if anyone has particular concerns with this pull request.
Mono-devel-list mailing list
Mono-devel-list <at>