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: absence of max Date: Wed, 30 Nov 2016 08:31:52 -0800 Organization: None to speak of Lines: 62 Message-ID: References: <0e1db67d-0ab8-4971-a319-8aa66a40b873@googlegroups.com> <436aadfe-20e5-4349-bdf4-9bac145b0d7e@googlegroups.com> <87oa0zi280.fsf@bsb.me.uk> <871sxvhw4i.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="3bc5dda710eeebf204839babe4155a1c"; logging-data="9101"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+28HdCwlDKncvdZTseMffw" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:MmXNXbJ2RQrnyYFVwSnCjAaI4Ag= sha1:s/yXQ9YjEBRp3GOoPFaefgkBmUM= Xref: csiph.com comp.lang.c:97781 BartC writes: [...] > C has effectively decided that any individual variable, any element in a > mixed-type struct, a single scalar parameter, a blind pointer to > anything at all, can be considered to be a 1-element array, and > therefore fair game to be used as though it /is/ an array, whether it is > in actuality or not. Yes, it has. N1570 6.5.6p7: For the purposes of these operators, a pointer to an object that is not an element of an array behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type. where the phrase "these operators" refers to the "+" and "-" operators taking a pointer and an integer as operands. I'm glad you understand that. > And because the rules of the language allow it (and therefore turn any > nonsense use of indexing into a mere out-of-bounds error, passing the > buck to the programmer), none of the experts here are going to say there > is anything wrong with it. They can't. I don't say there's anything wrong with it because, in my humble opinion, there isn't anything wrong with it. I can see that there could be some disadvantages to it. Perhaps I might incorrectly assume that a pointer points to an element of an array, and index it incorrectly -- though that's just one example of the fact that C doesn't require array index checking. I can imagine a C-like language that has two kinds of pointers, one supportint pointer arithmetic and therefore array indexing, and another that can only point to a single object and cannot be used to access other objects that are elements of the same array. Perhaps that would be a good idea. But C is not that language. (And if such a feature were added, I presume that it would still be possible to convert one kind of pointer to the other, overriding any protection. There is something to be said for requiring such overriding to be explicit -- but again, C is not that language.) There are also some advantages to the way C does it. Maybe I have a function that iterates over the elements of an array, and I want to use it on a single object that's not explicitly an array element. You clearly understand the rule. You understand, I presume, that the rule cannot be changed in a future version of the language without breaking existing code. You understand that most C experienced programmers don't have a problem with it. *We* understand that you don't like it. (We don't understand what the [deleted] you expect us to do about it.) By all means let us know if you have anything *new* to say on the topic. -- 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"