On Mon, 2009-11-23 at 22:22 +0100, Andreas Fritiofson wrote: > On Sun, Nov 22, 2009 at 12:42 PM, Øyvind Harboe <oyvind.har...@zylin.com> > wrote: > > On Sun, Nov 22, 2009 at 11:04 AM, Andreas Fritiofson > > <andreas.fritiof...@gmail.com> wrote: > >> On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe <oyvind.har...@zylin.com> > >> wrote: > >>> Do not use variable length arrays. Use malloc(). > >>> > >>> If you use variable length arrays on the stack that messes with embedded > >>> / uCLinux hosts. > >>> > >> > >> Only if the embedded host uses a home directory path longer than what > >> will fit on the stack. Is this really a problem? > > > > Yes. Other programmers will copy and paste your code. > > > > We've got the code clean of dynamic arrays on the stack and we > > should keep it that way. > > > > Since C99 has been accepted as the project's language standard, I > think it is reasonable to expect that valid language constructs that > are still *not* acceptable by the project be clearly stated in the > Style Guide. Likewise if being optimized for embedded hosts is a > priority for the project as a whole. Rejecting even trivial patches on > the grounds of previously unspoken goals does not encourage developers > to contribute.
If it makes you feel better, I think we have started using variable length arrays elsewhere in the code, but this is one place where I think it does make sense to keep things off the stack. > With that said, I'll happily resign in this case. Actually, my first > draft was using asprintf() but I rejected it for not being standard. > Seeing there's an equivalent already in the code, I'll update the > patch using that. It would probably be best to use asprintf when it is available, but we probably need to provide our own implementation... which would be known as alloc_vprintf in current terms. Icky name. > However, alloc_vprintf() seems to have a rather cumbersome > implementation. Is there a reason why it is looping, trying with > increasingly larger allocations? I was reviewing this code today, and it's due for a serious overhaul. IIRC, there should be at most 2 passes through that loop, but that would be a cheap and fast fix. Feel free to submit patches to clean this up, as you'll be saving me time doing it! :) --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
