Hacker News Reader

Comment by eliasmacpherson | Hacker News Reader

I never liked those microsoft functions, and disable all the warnings in each new project. What are you supposed to use instead of memcpy? It's a bit of a rant but I find myself in agreement with this:

http://unspecified.wordpress.com/2009/05/16/microsoft-bans-m...

View on HN

memcpy_s:

http://msdn.microsoft.com/en-us/library/dswaw1wk(v=vs.80).as...

edit: I read the link you included and I have to take exception with this line:

    it’s a perfectly safe function if you use
    it properly

Sure, same thing as automobiles, alcohol, condoms… Problems arise because people do not use them correctly.

LOL, That's a fucking joke!

"If the source and destination overlap, the behavior of memcpy_s is undefined."

Wow, way to improve things microsuck! It's not like anyone has ever mistakenly used memcpy on overlapping buffers....

The same is true for memcpy ya know... that's what memmove is for. Perhaps you should make sure you know what you're talking about before bashing others ("others" who are probably far more experienced than yourself).

Eh, I believe that was his point. If you're going to go to the trouble of building a safe memcpy with no sharp corners, don't leave the overlapping buffer razor blade sticking out. Perhaps you should settle down.

Hmmm... well perhaps I did miss that, but your (his?) suggestion is a terrible idea. memcpy should be fast. Checking for overlap slows it down. Want to allow for overlap? Use memmove, that's what it's there for. I don't want to have to roll my own optimized version of memcpy when I know that I don't need any special handling or error checking.

"memcpy should be fast"

you know memcpy is my 'classical' example of why you should never trust library code to be well optimised. its almost always a dumbass byte-by-byte copy - its pretty much the worst case performance unless you go out of your way to slow down your implementation.

the speed improvement from good register usage and appropriate cache hints was >35% the last time i had to do this (iirc against the VS 2008 implementation)

MS provided a special memcpy variant for 360 that did this for you using the PPC dcb* instructions and good use of the wider registers.

Am gobsmacked by the differences in benchmarks:

http://nadeausoftware.com/articles/2012/05/c_c_tip_how_copy_...

http://software.intel.com/en-us/articles/memcpy-performance

this looks pretty recent, good to know that memcpy is improving (maybe). i suspect the reason icc is winning so hard is exactly what i mention - cache hints and good register usage. the things is that stuff isn't new... its much more than 10 years old now.

no memcpy implementation has an excuse to be that slow under any compiler imo.

i'd imagine the intel guys will make use of this stuff because its why they put it in the hardware to start with... :)

incidentally, as a complete tangent, really great bunch of guys to work with if you get the chance - at least in my experience. a definite passion for and focus on performance in a serious way. :)

I did say "should" :D

You can use memmove_s, you know.

Those aren't "Microsoft functions"; they're C's optional Annex K functions which Microsoft happens to mostly implement (though in true MS fashion, they did manage to get a few wrong before the standard was finalized).

They were Microsoft functions long (6 years?) before they were standardized.

Microsoft led the standardization process for the Annex K functions.

> They were Microsoft functions long (6 years?) before they were standardized.

And most of what's in ANSI C (the first C standard, before ISO stepped in, from 1989) was in C compilers before ANSI C existed. I think void and void* were the only things ANSI C really added to the language.

My point is, the C standards body likes to standardize common usage, and 'what a Microsoft compiler does' is pretty close to being common in some parts of the world.

They also 'standardised' threads which were hardly common usage.

> They also 'standardised' threads which were hardly common usage.

Didn't the POSIX standard do that, as opposed to the ANSI C standard?

Sorry no, I was referring to the C11 multi threading stuff. http://en.cppreference.com/w/c/thread They are not exactly the same as POSIX threads which were standardised in 1995.

Well, yes, for operating systems that implement POSIX. Which doesn't account for all of them, last I checked.

Microsoft put in the deprecated warnings long before C11. Thanks for pointing out that they were made part of C11.

It's a little amusing that MS have this optional part of C11 implemented years in advance and standardised on their work, but haven't got C99 support. It must suit them to have it that way.

Can you tell me whether the C11 Bounds checking stuff from this optional Annex K had fully made it in to GCC 4.9? If not what's missing?

On the status page here it implies the project has had issues:[0]

[0]http://gcc.gnu.org/wiki/C11Status

Yet, on the release notes it says "Substantially complete" but it's really as clear as mud whether it's all there[2].

[2]http://gcc.gnu.org/gcc-4.9/changes.html

I suppose that on Linux and Windows the intel compiler relies on the GCC/MS implementation of memcpy_s.

Reply on news.ycombinator.com