[ 
https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael H. Schloming updated PROTON-57:
--------------------------------------

    Fix Version/s: 0.4
    
> Proton porting problems between current codebase and Visual Studio 2010 
> toolset
> -------------------------------------------------------------------------------
>
>                 Key: PROTON-57
>                 URL: https://issues.apache.org/jira/browse/PROTON-57
>             Project: Qpid Proton
>          Issue Type: Improvement
>          Components: proton-c
>         Environment: Windows using Visual Studio 2010
>            Reporter: Mary hinton
>              Labels: build
>             Fix For: 0.4
>
>         Attachments: codec.c.patch, messenger.c.patch
>
>
> 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
> #else
>         #define PN_VLA(TYPE, buf, size)     TYPE *buf = (TYPE*)  
> _malloca(size)
>        #define PN_VLA_FREE(buf)              _freea(buf)      
> #endif
>     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: http://www.atlassian.com/software/jira

Reply via email to