Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: usecases of void foo(char **b) {} Date: Sat, 05 Nov 2016 14:04:50 -0700 Organization: None to speak of Lines: 57 Message-ID: References: <87ins5k15t.fsf@bsb.me.uk> <87bmxxm6zs.fsf@gmail.com> <871syrijhw.fsf@bsb.me.uk> <8737j7gd87.fsf@bsb.me.uk> <87twbmfzah.fsf@bsb.me.uk> <87fun6f1j4.fsf@bsb.me.uk> <877f8hgb0p.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="068e13fa936d4e49cf562f96621eaf4d"; logging-data="30532"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+W3zenuyqctQk3Of3OJydw" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:tBaaB6mbKg2Eb2YTZMwbrr8/LtI= sha1:rph63Y1txQpWmqudio5haOGa59Q= Xref: csiph.com comp.lang.c:95853 BartC writes: > On 05/11/2016 16:13, Ben Bacarisse wrote: >> BartC writes: > >>> What you, Keith et al seem hung up about is that, for A to access its >>> own array, the language introduces a notional 'pointer' to that array >>> even though it doesn't exist in reality (other than needing to use its >>> address in the same way it needs to use the address of i to get at its >>> value). >> >> No, I'm hung up on you saying that an extra * is needed in the source >> code. > > Yet you presumably have no problem with using my method (adding a > pointer to a type, using & on an argument, and using an extra * in the > function), when passing a reference to a struct, int or float? It's just > array times that need special treatment. (Inconsistency #1) Yes, C's treatment of structures and its treatment of arrays are quite different. We already knew that. > (And no one has yet answered my question about how you idiomatically > pass an array when the array details are hidden behind a typedef. > Inconsistency #2) If possible, don't define a typedef for an array type. If you must do so, make the name clearly imply that it's an array type, so code that uses it can handle it properly. And if you still insist on making an array type opaque, provide a well defined interface for any functions that use it, so callers don't have to care that it's an array. For example, the type jmpbuf is required to be an array type, and setjmp() and longjmp() are the only standard functions that deal with it. FILE could be an array type, but all functions that manipulate it take a FILE* argument. Can this be awkward? Sure. But most of us understand it and deal with rather than whining about it. [...] > I've been writing native code to access arrays, and generating native > code to access arrays, for many many years. To me u[4] is not what > anyone would call a pointer access. Not anywhere outside of the C language. Outside the C language, you can think of it any way you like. Did you not notice the name of this newsgroup? [] is a pointer operation whether you like it or not (and whether I like it or not). [...] -- 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"