http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660@Chris Smith: I suspect a naive loop comparing a single byte at a time be *much* slower than memcmp. One of the reasons is that memory operations on bytes take the same time as memory operations on a whole memory word (and depending on cache considerations, even more than that). Besides, memcmp is probably optimized to take advantage of SSE/SSE2 instructions.http://ayende.com/118785/what-is-wrong-with-this-code#comment14http://ayende.com/118785/what-is-wrong-with-this-code#comment14Mon, 17 Oct 2011 08:47:53 GMTThat's a valid case then. Thanks. Can't you just do it in managed code then you don't have to worry about pinning, pinvoke and all that? It's probably not much slower (I can't claim to have tried it or worked out what the CLR assembles it to though). bool memcmp(byte[] a, byte[]b, int len) { for (int i = 0; i >= 0; i++) if (a[i] != b[i]) return false; return true; } That's rougly what a platform independent C implementation does albeit with less pointer magic and minus some optimisations (that glibc does at least) which do it in aligned 4/8 byte blocks for CPU efficiency.http://ayende.com/118785/what-is-wrong-with-this-code#comment13http://ayende.com/118785/what-is-wrong-with-this-code#comment13Fri, 14 Oct 2011 18:10:29 GMTChris. For example, when I need to compare data that comes from unmanaged code. I have an index that output data that I need to sort based on their memcmp valueshttp://ayende.com/118785/what-is-wrong-with-this-code#comment12http://ayende.com/118785/what-is-wrong-with-this-code#comment12Fri, 14 Oct 2011 07:29:02 GMT> Can anyone give an example of when this might be used in production .NET code. That's exactly my problem. This seems an overly hypothetical question.http://ayende.com/118785/what-is-wrong-with-this-code#comment11http://ayende.com/118785/what-is-wrong-with-this-code#comment11Fri, 14 Oct 2011 07:27:42 GMT1. Your declaration of memcmp doesn't match the one in pinvoke.net, which is usually correct It has the wrong calling convention, parameter type (although it is the same size so should be safe), and return type (IntPtr instead of int) [DllImport("msvcrt.dll", CallingConvention=CallingConvention.Cdecl)] static extern int memcmp(byte[] b1, byte[] b2, UIntPtr count); You are likely to get a PInvoke stack imbalance in one of x86 or x64. 2. b2.Length could be more than b1.Length; if b2 is equal to the first b2.Length bytes of b1, memcmp would continue after the end of the array. 3. Both b1 and b2 could be null; b1 would cause a NullReferenceException, b2 would cause a segfault. 4. If the b1 is over 2GB in size, b1.Length would break. Use LongLength instead; it is safe to cast it to an IntPtr because an array couldn't be larger than int.MaxValue on a 32-bit system.http://ayende.com/118785/what-is-wrong-with-this-code#comment10http://ayende.com/118785/what-is-wrong-with-this-code#comment10Thu, 13 Oct 2011 14:54:41 GMTI am seeing the failure due to the byte stream potentially being longer than what an int can hold.http://ayende.com/118785/what-is-wrong-with-this-code#comment9http://ayende.com/118785/what-is-wrong-with-this-code#comment9Thu, 13 Oct 2011 14:14:13 GMTmemcmp returns an int, not an IntPtr. Will probably cause some stack corruption. The GC is not a problem though.http://ayende.com/118785/what-is-wrong-with-this-code#comment8http://ayende.com/118785/what-is-wrong-with-this-code#comment8Thu, 13 Oct 2011 13:45:42 GMTThe obvious problem is that b2 can contain lesser bytes than b1. And not so obvious is that using IntPtr instead of UintPtr may produce stack imbalance on x86 platforms.http://ayende.com/118785/what-is-wrong-with-this-code#comment7http://ayende.com/118785/what-is-wrong-with-this-code#comment7Thu, 13 Oct 2011 11:52:00 GMTCould be a problem that IntPtr don't have the same size on a 32 or 64-bit process. Since a.NET dll may be compiled to run in processes of any address size this could potentially drive you silly when you e.g. coolly run shit on a big server and do tests with MSTest. When I look at the memcmp docs, it actually wants pointers? I am wondering if that is not a source of mishap...http://ayende.com/118785/what-is-wrong-with-this-code#comment6http://ayende.com/118785/what-is-wrong-with-this-code#comment6Thu, 13 Oct 2011 11:11:02 GMTNull reference exception - if b1 is null b1.Length will boom. If b2 is null well, I'm not sure, but it will probably crash. Returning IntPtr makes no sense whatsoever - it should be plain int - I'm not sure now if this will return 0 as IntPtr.Zero (probably will) There's actually usage example on pinvoke.net: http://www.pinvoke.net/default.aspx/msvcrt.memcmphttp://ayende.com/118785/what-is-wrong-with-this-code#comment5http://ayende.com/118785/what-is-wrong-with-this-code#comment5Thu, 13 Oct 2011 10:38:34 GMT@Max - objects passed to P/Invoke don't need to be pinned, unless the unmanaged code is going to be keeping a reference - the GC won't move them during the P/Invoke call.http://ayende.com/118785/what-is-wrong-with-this-code#comment4http://ayende.com/118785/what-is-wrong-with-this-code#comment4Thu, 13 Oct 2011 10:26:04 GMTCan anyone give an example of when this might be used in production .NET code. Thankshttp://ayende.com/118785/what-is-wrong-with-this-code#comment3http://ayende.com/118785/what-is-wrong-with-this-code#comment3Thu, 13 Oct 2011 10:25:32 GMTWell, simple one is the assumption that b2 is at least as long as b1 (otherwise, you're wandering into other memory, possibly crossing a page boundary into memory that isn't there)http://ayende.com/118785/what-is-wrong-with-this-code#comment2http://ayende.com/118785/what-is-wrong-with-this-code#comment2Thu, 13 Oct 2011 10:18:20 GMTWell, the memory for the byte arrays is not pinned, so if the GC moves the byte arrays during a garbage collection you will get some really strange results, which could include a segfault. Furthermore, even if the GC doesn't move the arrays, you may get a segfault if the length of b2 is less than that of b1. If the length of b2 is less than that of b1 then you may just get a wrong result. Lastly, I'm not sure if the representation of a byte[] is guaranteed to be the same as char* but I guess it is not - in particular it must include at least the length. So the check may return a bogus result even if the GC doesn't move things AND the byte arrays are the same length.http://ayende.com/118785/what-is-wrong-with-this-code#comment1http://ayende.com/118785/what-is-wrong-with-this-code#comment1Thu, 13 Oct 2011 10:16:31 GMT