2

For different purposes I need to provide an interface that implementents the following functions in C#

  • malloc
  • calloc
  • realloc
  • free

But I would prefer to not to code it myself (why reinvent the wheel). A better solution would be when my alloc-functions was called, I would simplely call the alloc-functions in stdlib.h, the interface is made so I "just" need to call those functions.

The question is, how do I access the functions in the stdlib.h from C#? I know about platform invoke, and I am getting better at it. But for platform invoke to work, I need a .dll And I don't know which .dll implements the stdlib.h

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
Mr. JWolf
  • 1,375
  • 2
  • 14
  • 33
  • Not mentioning your "purposes" is a big, big mistake. These C functions don't actually do anything but directly call the corresponding winapi functions. Like HeapAlloc(). A function that requires a handle to a heap. That handle value is *never* a small detail, very high odds that you'll end up with the wrong one. – Hans Passant May 09 '14 at 23:29
  • I'd be interested in hearing what type of problem would require direct access to these routines from C#, if you care to share. I'm struggling in my head to come up with a reason why I'd ever want to do that. – KevinS May 10 '14 at 01:39
  • The purpose for this case is, I have a 3. party libary which needs this interface. The reason the 3. party libary needs it, is because the libary is written to work on different platforms and work on embedded hardware. It also needs a file- and loghandler. – Mr. JWolf May 12 '14 at 08:19

1 Answers1

4

I don't think this sounds like the best solution for your problem. But to answer the question you first need to decide which C runtime to use. One possibility is the system component in msvcrt.dll. Access the functions like this:

[DllImport("msvcrt.dll", CallingConvention=CallingConvention.Cdecl)]
static extern IntPtr malloc(IntPtr size);

[DllImport("msvcrt.dll", CallingConvention=CallingConvention.Cdecl)]
static extern void free(IntPtr ptr);

[DllImport("msvcrt.dll", CallingConvention=CallingConvention.Cdecl)]
static extern IntPtr calloc(IntPtr num, IntPtr size);

[DllImport("msvcrt.dll", CallingConvention=CallingConvention.Cdecl)]
static extern IntPtr realloc(IntPtr ptr, IntPtr size);

However, the official position from MS is that msvcrt.dll is private and not for use by third party applications. So you might prefer to link to a C++ runtime associated with a specific version of MSVC. For example, to link to the VS2013 runtime specify msvcr120.dll. This of course would require you to distribute that runtime.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • 1
    Can't upvote this because you're recommending using a [reserved CRT](http://blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx) that could be removed at any time (Per MS docs you're not supposed to link to it) – Mgetz May 09 '14 at 22:51
  • @Mgetz alternatively link to a different C runtime then. However, any system component is subject to potential future removal. – David Heffernan May 09 '14 at 22:53
  • Thanks for the answer, what would you recommand I do? The problem at hand is that I need to provide these functions. – Mr. JWolf May 09 '14 at 22:55
  • And, should I include msvcrt.dll in my project, or the system knows exactly where msvcrt.dll is? – Mr. JWolf May 09 '14 at 22:56
  • I don't know enough about your problem to recommend a solution. msvcrt.dll is a system component. It is part of Windows. – David Heffernan May 09 '14 at 22:57
  • Thanks for the answer and for the info. This is sufficient (for now ;) – Mr. JWolf May 09 '14 at 23:02