Mary hinton created PROTON-57:

             Summary: Proton porting problems between current codebase and 
Visual Studio 2010 toolset
                 Key: PROTON-57
             Project: Qpid Proton
          Issue Type: Improvement
          Components: proton-c
         Environment: Windows using Visual Studio 2010
            Reporter: Mary hinton

This thread will be used to discuss the porting problems encountered using 
Visual Studio 2010

Here’s the first one to discuss:
1. Visual Studio doesn’t support variable length arrays. 
    a.  Currently using malloc()/realloc() in my port just to get it to compile 
and be able to report memory allocation errors. This is not what I want to 
submit to the proton group for memory allocation.

    b.  Cliff had a good method that included  setting up macros and replace 
the VLAs with  alloca() in the Windows version, but it could still cause 
problems when the stack overflowed. VLAs can also run out of stack space.

    c.  _malloca() should be a better way than _alloca() on Visual Studio. Any 
messages under 1K would be allocated out of the stack. Over 1K will use heap. 
If the average messages are under 1K, this may be the most efficient way in 
Visual Studio. _malloca() also has new security enhancements. 
        1.  Using _malloca() in the Windows version and VLA in Linux would 
require two macros. The major difference for the Linux version would be to use 
the new macro for VLA and to include the new free macro even though there is 
nothing to free using VLA.  In Visual Studio, _freea(buf) will not free 
anything if it is allocating off the stack.
Linux can continue to use VLAs.

#ifdef C99                      
        #define PN_VLA(TYPE, buf, size)     TYPE buf[size]
        #define PN_VLA_FREE
        #define PN_VLA(TYPE, buf, size)     TYPE *buf = (TYPE*)  _malloca(size)
       #define PN_VLA_FREE(buf)              _freea(buf)        

    d. If the average size messages to allocate out of the stack needs to be 
increased for performance reasons, we can set up a new memory model. The 1K is 
not adjustable for _malloca().

We can set up new macros along the lines of Microsoft’s suggestion below.
 “I would suggest something similar to what ATL does.  Use alloca for small 
(where you define what that is) sizes and use heap allocation for larger ones.  
You can wrap the logic inside of a class or macros.  To work around the fact 
that alloca isn't cleaned up at block scope, rewrite the block into functions 
or use lambdas.  (I think alloca works inside of lambdas.)”

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

Reply via email to