Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!transit3.readnews.com!panix!not-for-mail From: jgk@panix.com (Joe keane) Newsgroups: comp.std.c Subject: Re: VLAs use less stack Date: Sun, 2 Sep 2012 16:56:55 +0000 (UTC) Organization: Public Access Networks Corp. Lines: 19 Message-ID: References: NNTP-Posting-Host: panix3.panix.com X-Trace: reader1.panix.com 1346605015 19813 166.84.1.3 (2 Sep 2012 16:56:55 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Sun, 2 Sep 2012 16:56:55 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Xref: csiph.com comp.std.c:1649 In article , Keith Thompson wrote: >How common is that in practice? In the absence of VLAs, if you don't >know in advance how big the buffer needs to be, isn't it more common to >use malloc() (and possibly realloc())? That is the only way to handle the general case. fixed-size array: fails at some point (can check for this) and variable-size array: fails at some point (can't check for this) >Interesting idea. But I wonder how often it's really worthwhile >in practice. In terms of code complexity, it offers no advantage >over using malloc/free uconditionally; you still have to make sure >you call free() if the buffer was allocated with malloc(), so you >lose that advantage of VLAs. It is useful. It's simply profiling. If you find too much time spent in malloc and free, fix it somehow... This is one way.