Ian Collins wrote: > 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?
Yes (which looks at the macro-private pointer whether it is |NULL| (=memory was allocated via VLA from stack) or not (=memory comes from |malloc()|)), otherwise we would have a leak... ;-/ [snip] > >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. Right... > Consider something like > > char buffer[max_consumer_size+string_length]; > > Give the constant for 140 a descriptive and and save yourself a comment. Maybe a #define is better here since some compilers add an extra symbol which is IMO not worth the space in the resulting binary... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
