Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Future of C Date: Wed, 14 Mar 2018 10:45:22 -0700 Organization: None to speak of Lines: 80 Message-ID: References: <0231327b-9e28-46e4-9178-46c881a8dd91@googlegroups.com> <20180310180016.eda9bc36e1a3b182bc2563a8@gmail.com> <20180311000302.8e7cd15242a818ab75eb2e98@gmail.com> <83527acf-abed-4f8f-878c-7d4db9cd5ac1@googlegroups.com> <20180311161525.ac591de531b83d6b14b2cd43@gmail.com> <90236828-48d7-4ee5-9b86-4cedd0e29b5f@googlegroups.com> <3r7jne-t3h.ln1@gangtai.grep.be> <8e201938-ada4-42d9-8ae6-13b1047306e2@googlegroups.com> <4dYpC.2767$dj4.608@fx07.am4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="afe9607107c97cf059941548cf335e32"; logging-data="22814"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19+W1tG+fW9KwRolhmFOIiR" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:2oJVkHzjMWPnjNlj63EFvoN5knw= sha1:XqGQrMiLRvzJKXjawG2kYOG7qhw= Xref: csiph.com comp.lang.c:127812 bartc writes: [...] > But if you want standard C VLAs, try the following program. It doesn't > do anything more ambitious other than allocating VLAs - of the same size > each time - within an ordinary loop. My table becomes: > > Compiles? Runs? (using fred(4096)) > > Pelles C Yes Yes > Lccwin Yes Erratic (usually runs, sometimes crashes) > DMC Yes Crashes > Tiny C Yes Crashes > MSVC No --- > gcc 5.1.0 Yes Yes > clang Yes Yes (via rextester.com) > mcc No --- (my product) > Any C++ No --- [not tested] > > Support is much better than before, but still not exactly unanimous. > > (The problem with the crashing is likely to be due to reallocating each > new VLA instance before deallocating the old, so overflowing the stack) > > ---------------------------- > void fred(int n){ // fred(4096) > typedef int T[n/2]; > for (int i=0; i<1000; ++i) { > printf("Sizeof(T) = %d N=%d %d\n",(int)sizeof(T),n,i); > T A; > int B[n]; > printf("Sizeof(A) = %d N=%d\n",(int)sizeof(A),n); > printf("Sizeof(B) = %d N=%d\n",(int)sizeof(B),n); > puts(""); > } > } Here's my version of your program: #include void fred(int n){ // fred(4096) typedef int T[n/2]; for (int i=0; i<1000; ++i) { // printf("Sizeof(T) = %d N=%d %d\n",(int)sizeof(T),n,i); T A; int B[n]; // printf("Sizeof(A) = %d N=%d\n",(int)sizeof(A),n); // printf("Sizeof(B) = %d N=%d\n",(int)sizeof(B),n); // puts(""); printf("A at %p, %zu bytes ", (void*)&A, sizeof A); printf("B at %p, %zu bytes\n", (void*)&B, sizeof B); } } int main(void) { fred(4096); } With gcc, clang, and the latest tcc, it produces 1000 identical lines of output, indicating that the VLAs are allocated and deallocated on each iteration of the loop. (The language doesn't require this, but it's an important QoI issue.) With lcc64 (lcc-win 4.1), it compiles without error and produces 1000 lines of output and then dies with a segmentation fault. The output shows the address of A remaining constant, but the address of B changes with each iteration, indicating a possible memory leak. (jacob has not acknowledged my recent report of another bug, so perhaps someone else can tell him about this if he's interested.) With DMC, the program compiles without error, but it produces no output. DMC does support VLAs, so this appears to be a bug. Pelles C handles it correctly. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"