vc 2005 intrinsics

The new VC compiler does not inline memcpy when buffer size is not known at compile time. Is it possible to somehow force it to do so?
I have a project that does not use CRT, only basic intrinsics (strlen, memcmp, memcpy), and with new VC generating reference to CRT lib executable grows up by few KB rubbish - I see some extra functions imported like RtlUnwind, TerminateProcess, GetCurrentProcess, UnhandledExceptionFilter, SetUnhandledExceptionFilter, IsDebuggerPresent. They seem unused though, as I set my own entry point, and memcpy does not use them either.. Shall I rewrite memcpy myself, or is it possible to discard this unwanted code that gets linked into executable? 

.

Relevant Pages

  • Re: vc 2005 intrinsics
    ... > The new VC compiler does not inline memcpy when buffer size is not ... > known at compile time. ... > I have a project that does not use CRT, only basic intrinsics (strlen, ... pulled in which in turn causes those other references. ...
    (microsoft.public.vc.language)
  • Re: [OT] Re: memcpy() vs. for() performance
    ... >> When the size is unknown at compile time, ... >> cannot inline the memcpy call, it will call the library version. ... >call it optimization. ... Dan Pop ...
    (comp.lang.c)
  • Re: VC 2003, WinXP and Win2000
    ... issue does not seen to occur at all under Win2k SP4. ... I am working with the wincrypt, and allocating a buffer to hold some ... first-chance exception under WinXP. ... memcpy() line to the following: ...
    (microsoft.public.vc.language)
  • Re: Efficient scather-gather-copy
    ... memcpythan external programs. ... I can't see that memcpy() would buy you much here, ... passes through the buffer: one to count the newlines and one to ... char *xlate (char *src, size_t len) ...
    (comp.lang.asm.x86)
  • Re: How to disable _SECURE_ATL macro
    ... deprecating memcpy in favor of ... > the problem with memcpy is that if you are interacting with code that you ... clearly defines the size of the buffer accessed. ... is about Secure SCL which most definitely is not "much safer". ...
    (microsoft.public.dotnet.languages.vc)