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: Tue, 13 Mar 2018 15:54:50 -0700 Organization: None to speak of Lines: 110 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="a9638e2b58572a27edc6516887e5eee0"; logging-data="21517"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ZaV1zD9/rKphzCbLsAUs9" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:KFb6p1nWSlg9SqEkj4lm0L1387Q= sha1:fEPJxj8p2GPznft2bRV+fpFAtDk= Xref: csiph.com comp.lang.c:127785 bartc writes: > On 13/03/2018 21:36, Keith Thompson wrote: >> bartc writes: >> [...] >>> A longer example is given below. Results are as follows: >>> >>> Compiles? Runs? (using fred(10)) >>> >>> Pelles C No --- >>> Lccwin Yes Crashes (or bad results without copy test) >>> DMC No --- >>> Tiny C Yes Crashes >>> MSVC No --- >>> gcc 5.1.0 Yes Yes >>> clang No --- (via rextester.com) >>> mcc No --- (my product) >>> >>> >>> So only one compiler out of 7 or 8 fully supports a feature that you say >>> is so easy to implement; funny, that. >>> >>> Or rather, 'not difficult' (so what /is/ difficult in your opinion?) >>> >>> (Here, I've hardly got started with the complexities of VLAs, like >>> multiple-dimensional VLAs of my VLA D type and allocating them in loops.) >>> >>> ------------------------------------- >>> >>> void fred(int n){ >>> typedef struct {int A[n],B[n/2],C[n*2];} D; >> [SNIP] >>> } >> >> N1570 6.7.2.1p9: >> A member of a structure or union may have any complete object type >> other than a variably modified type. >> >> Apparently gcc supports VLA members as an extension. clang does not. > > So, how hard can it be? According to David Brown, everything is easy, or > 'not difficult' (presumably by only doing the easy bits and declaring > anything else an error). I don't know how hard this particular extension was for the gcc folks to implement, but I hardly think David was talking about non-standard extensions, nor do I recall him using the word "everything" in this context. VLAs as struct members are non-standard, so the difficulty of implementing them is not relevant. I think what David actually said is that implementation VLAs in the manner required by the C standard is not inordinately difficult. > 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) Tiny C (tcc) 0.9.27 compiles and runs the program correctly on my system (Ubuntu). Note that tcc is no longer maintained. MSVC does not support VLAs, and they're not a feature of C++. That leaves 2 or 3 compilers on which the program compiles and (sometimes?) crashes. Perhaps you should submit bug reports. > ---------------------------- > 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(""); > } > } (Are you allergic to "%zu"?) If you replace your printf and put calls by: printf("A at %p, %zu bytes, ", (void*)&A, sizeof A); printf("B at %p, %zu bytes\n", (void*)&B, sizeof B); it will show the addresses and sizes of the VLA objects. If the address changes on each iteration, that's a clue that it might not be deallocating things 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"