[
https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474090#comment-13474090
]
Mary hinton commented on PROTON-57:
-----------------------------------
For the ones you want a fixed maximum length, is there a specific size for
printing the atoms and data that you want? The same with the maximum length
for the addresses, what size would you like to specify?
“pn_data_encode/decode(...) For these we should add a dedicated array to
pn_data_t and grow the array as needed.”
pn_data_encode() used a VLA for allocating atoms on the stack. Did you want me
to put in a pointer to atoms in pn_data_t and then allocate it out of heap and
if needed realloc() and free it in pn_data_free()?
> 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
>
> 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
