[osol-code] Re: [ksh93-integration-discuss] Trouble with"ERROR:ctfconvert:pics/wordexp.o: Couldn't parse stab "#vla0:(0, 14)"(source file pics/wordexp.o)" ...

[Ian Collins]

Roland Mainz wrote:

>Ian Collins wrote:
>  
>
>>Roland Mainz wrote:
>>
>It can't fail directly but you can hit the end of the stack. However for
>|libc::wordexp()| there is enougth room (for the SMF process (the only
>comsumer of |libc::wordexp()| in OS/Net (and I strongly doubt that other
>consumers are low on stack memory)) multiple megabytes are still
>available). For other applications it is usefull to have a macro which
>uses C99 variable length arrays up to a fixed limit and then switches
>over to use |malloc()| beyond that size (and sets the size of the vla
>buffer to zero).
>  
>
I assume you have a matching macro to call free in the case where malloc
is used?

>  
>
>>>>Speaking of which, where does "140" come from in the dynamic array
>>>>definition?  It would be better not to have a magic number like that.
>>>>        
>>>>
>>>It's no magic number, it is the maximum size the consumers of the buffer
>>>will use in any case.
>>>      
>>>
>>But it (140) is still a magic number, maybe make it a const size_t?
>>    
>>
>
>Uhm... AFAIK this is just a question of style, right ? |size_t
>sizeofbuffer=140+string_length ; char buffer[sizeofbuffer]| or  |char
>buffer[140+string_length]| are pretty much equivalent... but it may be a
>good idea to add a comment how the value "140" was calculated.
>
>  
>
It's more than style, good practice and most C coding standards state
that magic number in code are bad.

Consider something like

char buffer[max_consumer_size+string_length];

Give the constant for 140 a descriptive and and save yourself a comment.

Ian