Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.std.c Subject: Re: doubtful assumptions about pointers Message-ID: <11954@smoke.BRL.MIL> Date: 16 Jan 90 04:01:40 GMT References: <1250.25ab3338@csc.anu.oz> <11922@smoke.BRL.MIL> <1259.25ae2019@csc.anu.oz> Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 153 In article <1259.25ae2019@csc.anu.oz> bdm659@csc.anu.oz writes: >Don't put words into my mouth. I didn't necessarily mean to imply that this was YOUR motivation, but many similar discussions in the past have been based on such a formalist/rationalist point of view (to be charitable to them). >Forgive me if my memory is wrong, but I seem to remember a posting of yours >in which you agreed that the members of unions might not physically overlap >in some implementations. If you consider that pi might point to such a member, >there are difficulties in reconciling that posting with this one. Union members "overlap". In order to implement some forms of union on some unusual architectures, it may be necessary to use storage areas for different members that don't actually overlap. Nevertheless, it still conceptually is an overlap, and any program that assumes that one member value is unaffected upon storing into another member is not strictly conforming. This consideration doesn't affect the specific example of an int being accessed via a converted char pointer. An implementation may have some bits in its representation of an int that are "unused", and therefore modifying a part of the int via a char pointer might happen to not affect the represented value, depending on just where into the int representation the char* points. Assuming either that the value will be changed or that it won't be changed by such an operation also makes a program not strictly conforming. >... We are only given some functional axioms, from which >some desirable properties, like this one, don't obviously follow. Well, you know what I said about excessive rationalism. This was one example where an implementation could technical strictly conform without having the desirable property. As I said, I don't expect this to be a practical problem. The category "RA" would fit this and some others that I labeled "TA" when I meant "expected to be TA in practice, although not strictly logically deducible from the Standard's specifications". >Why does equal representation imply equal semantics? It doesn't, but if you think about how the implementation must use the representations in testing for pointer equality, it should be apparent that when two char*s compare equal, the corresponding void* conversions should compare equal. Again, a truly perverse implementation could possibly go out of its way to cause this to fail, but since it is harder to do that than to do it the obvious way, I also don't expect this to be a problem in practice. "RA" >An argument based on the existence of functions like memcpy() might show >DA[2] is an RA, though. Certainly memcpy() indicates what X3J11 thought void*s were supposed to be useful for. >Actually i is nonzero, though your argument still holds. However, the case >with i==0 is a more instructive DA (indeed FA as you say). Oops. >Anyway, alignment is defined as a requirement on objects; applying it >to the values of pointers which may not be pointers to objects seems >doubtful. As far as implementations are concerned, consider one which >treats pointers of kind P3 as a special case in representation (perhaps >to permit objects reaching to the end of memory segments). It may be >that making (int*)(char*) a no-op in this case could take more work, >not less. It would require a general slowdown in pointer operations to represent the P3 case in a manner not uniform with other object pointers. In any case, I would expect such an implementation to apply the same sort of local flat address space linearization that it must do for pointer arithmetic to the conversion of pointers. Since the size of an array includes padding, the "last+1" element of an array meets the same alignment constraints as the other array elements. "RA" >You missed my point. Suppose the body of the text said "Gismos are pink." >and the footnote said "This is meant to imply that gismos are pink and >crinkly.". What can we infer about gismos? Well, the only reasonable >inference is that gismos are both pink and crinkly, even though the footnote >is not supposed to be part of the standard. To me, this supports what I said about the problems introduced when one resorts to formalistic reasoning. You CANNOT understand a concept by merely substituting its definition for all linguistic uses of the concept. A concept in general subsumes more than the definition would imply; there are other relevant properties. When the Standard says that two types have the same representation and alignment requirements, it means that IN ALL CONTEXTS they have the same r&a requirements. That does imply what footnote 15 says; the footnote was added as a result of public review comments because we kept getting asked "Does this also mean when used as function arguments?". Note that there may be different contextual r&a requirements for the same type used as: static automatic register volatile string literal function argument function parameter function return value and in still other contexts. A context-free constraint on r&a requirements must be applied appropriately in all contexts. >from the Forward: "[pANs] addresses the problems of both the >program developer and the translator implementor by specifying the >C language precisely." Are you saying it fails to meet this claim? Precision is a matter of degree. The ANSI Standard is considerably more precise than K&R Appendix A. It need only be sufficiently precise to fulfil its role as reference treaty between programmer and implementor. >I wish to test things for strict conformity by applying the definition that >the standard gives. If it isn't "specified in this Standard", it isn't >strictly conforming. Conformance tests should not flag behavior as a violation if it is not possible to relate it to explicit wording in the Standard, even if it is insane behavior, if the result of such testing might end up in litigation. These "RA" cases deserve to be uncovered, however, since many applications are and will be assuming reasonable implementations and the programmer should hear about it if an implementation goes out of its way to introduce unwarranted obstacles. >(2) One person's "perverse" is another person's "reasonable". My notion of a perverse implementation is one that deliberately exploits an ambiguity in the specification, with considerably more effort than would be required to implement "reasonable" behavior such as would be expected by experienced C programmers, to force portable programs to use complex code to avoid triggering the perverse behavior. If someone else thinks such an implementation should be deemed reasonable, he's disconnected from the real world of computer programming. This does not include reasonable implementation choices that are forced by the architecture or environment, just those for which there is no good reason. As an example of how an implementation can be perverse, suppose that a POSIX implementation really literally obeyed the last word of the specification in IEEE Std 1003.1-1988 section 8.2.3.4. While that would be literal conformance to the specification, and while a reasonable implementation would have to violate that part of the specification, it would nevertheless be perverse to obey that spec, which is obviously an error due to incomplete editing of text copied from scetion 8.2.3.2.