Path: csiph.com!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: Fri, 04 Nov 2016 09:05:33 -0700 Organization: None to speak of Lines: 121 Message-ID: References: <87mvhjo3jw.fsf@bsb.me.uk> <3a09f5ec-d4f7-40fa-9855-b5c3f02ce4e9@googlegroups.com> <87ziljks6k.fsf@bsb.me.uk> <2199a2dd-d844-4f8d-bfe0-6a7c2854277b@googlegroups.com> <87twbqlsin.fsf@bsb.me.uk> <87oa1yljof.fsf@bsb.me.uk> <87ins5k15t.fsf@bsb.me.uk> <87bmxxm6zs.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="6f57f3023f7434c61f7dba030433622e"; logging-data="28481"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19MvghpS3ze1B891/4A8Thh" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:1mL8Vws36HF5spa3bOLyYA9tOq4= sha1:Awd+vePyDRyxDu9CwCVww7dHy1c= Xref: csiph.com comp.lang.c:95758 BartC writes: > On 03/11/2016 19:12, Keith Thompson wrote: >> BartC writes: > >> Applying the indexing operator adds the value of `i` to that int* >> pointer expression, yielding a new int* value, and dereferences it. So >> `(*ptr)[i]` is an lvalue designating an object of type int (specifically >> that object is an element of array_object, defined in main()). Given >> the context in which it's used, *lvalue conversion* is applied, yielding >> the value of the object -- either 10, 20, or 30, depending on which >> iteration of the loop we're on. > > You've completely lost me there. Then you don't understand C. You've somehow managed to use it without understanding it, which I suppose is some kind of accomplishment. > If you start with a pointer to array, and apply a dereference, then > you get an array. Yes. > Then you index that array to get one of its > elements. No, the indexing operator requires a pointer and an integer (the pointer must point to an element of an array object). I know you *want* it to take an array operand. It just doesn't. > You're being put off by the fact, that, half-way through, C might > implode if it has to deal, even temporarily, with an entire value > array. That doesn't happen because of the following index. I'm not being put off by anything. There is no implosion. The indexing operator doesn't prevent dealing with an "entire value array"; the language rules do. The array expression is converted to a pointer expression because it's not in one of the contexts where the conversion doesn't occur. The subsequent indexing operator is legal because of that conversion, but it doesn't cause it. > If you had a very large struct S, with member m, then evaluating S.m > doesn't mean having to somehow load the entire struct before > extracting that one field. Certainly there's generally no need to load the entire structure. (It might be required if the prefix is the name of a volatile structure object; I'm not certain about the required semantics in that case.) > (There's some subterfuge in both cases to prevent that happening. It > happens in all (sensible) languages. It's doesn't need a special > language rule that decays any pending value arrays to pointers; it's > handled behind the scenes for all potentially large data such as > arrays and structs.) The standard is very clear about how array indexing works. Your refusal to accept what it says is irrelevant. > But let me repeat that first bit: > > If you start with a pointer to array, and apply a dereference, then > you get an array. Then you index an array to get one of it's element. > > That's all the programmer needs to know. All the 'idiomatic' stuff is > playing with blocks of memory, pointers, and offsets Your non-idiomatic code also plays with pointers, and in a more complicated way than the idiomatic version. You just refuse to acknowledge it. >> Aside from that, you seem to be objecting to the fact that you can pass >> the address of a single object to a function that's intended to operate >> on an array. That's not a bug, it's a feature. For purposes of pointer >> arithmetic, a single object can be treated as a single-element array, >> and something like: >> >> int foo; >> func0(&foo, 1); >> >> is perfectly valid. If you want to prevent that kind of call, well, I >> guess you can do so by writing non-idiomatic code that takes an array >> pointer. But it hardly seems worth it. > > Yes, I think this was well-covered some months back. Some potentially > catastrophic bug is a 'feature'. A function takes a int* for an array, > and an int* for an 'in/out' length (for some processing it will do). Treating an object as a 1-element array is a "catastrophic bug"? And it's worth mangling your code to prevent the caller from doing it? > Except that the caller passes the arguments in the wrong order. The > compiler says nothing. Eventually - hopefully - the mistake will be > discovered. The function we were talking about takes a pointer and an integer. If you pass the arguments in the wrong order, the compiler will complain. If I wanted to pass a pointer to an object holding the length, I'd use size_t*, not int*, and again the compiler would complain if I swapped the arguments. You're inventing problems. >> I've used a number of different programming languages. Rather than >> trying to use idioms from language X in language Y, I prefer to approach >> each language on its own terms. It makes for code that's much easier to >> read for poeple familiar with the language I'm writing in. And, every >> now and then, I learn something. I don't always *like* the idioms of >> whatever language I'm using, but fighting against them would be a waste >> of time. > > Have you ever thought that one day you might want to take your C code > and port it to a language that takes a more disciplined approach to > array-handling? You'd find it a lot easier if you used that array > approach in C! Not particularly, no. And I'd find it much easier to port idiomatic C code that I understand. -- 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"