[ 
https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13471785#comment-13471785
 ] 

Mary hinton commented on PROTON-57:
-----------------------------------

proton.c                                        
      server_callback(pn_connector_t *ctor)      --  char iresp[n];
                                  --  char data[ctx->size + 16];
      client_callback(pn_connector_t *ctor)       --  char msg[ctx->size]
                                                                         --  
char  data[ctx->size + 16];

codec.c
      pn_print_atoms(const pn_atoms_t  * atoms)         -- char buf[size]
      pn_data_encode(pn_data_t *data, char *bytes, size_t size) --  pn_atom_t 
atoms[data->size + data->extras];
      pn_data_decode(pn_data_t *data, char *bytes, size_t size) --  pn_atom_t 
atoms[asize];
        
messenger.c
      pn_messenger_resolve(pn_messenger_t *messenger, char *address, char 
**name)         -- char domain[strlen(address) + 1];
      pn_messenger_link(pn_messenger_t *messenger, const char *address, bool 
sender)      -- char copy[(address ? strlen(address) : 0) + 1];
      pn_messenger_subscribe(pn_messenger_t *messenger, const char *source)     
  -- char copy[strlen(source) + 1];
      outward_munge(pn_messenger_t *mng, pn_message_t *msg)                     
  -- char buf[len + strlen(mng->name) + 4];     
                                                                  -- char 
buf[strlen(mng->name) + 4];
      pn_messenger_put(pn_messenger_t *messenger, pn_message_t *msg)            
           -- char encoded[size];
        
sasl.c
      pn_sasl_plain(pn_sasl_t *sasl, const char *username, const char 
*password)                --   char iresp[size];
      pn_fprint_data(FILE *stream, const char *bytes, size_t size)              
                             --   char buf[capacity];

This list only includes the VLAs and doesn't include constant size arrays.

                
> 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

Reply via email to