bdm@anucsd.oz (Brendan McKay) (10/17/89)
Oops. I shouldn't have replied from home without my copy of the standard. >> (D) Doug Gwyn <gwyn@smoke.brl.mil> >> No, we didn't -- any valid pointer can be converted to a pointer that >> has less strict alignment and back, so that the result compares equal >> to the original pointer, > I can only find this rule for OBJ* -> void* -> OBJ* and OBJ* -> char* -> OBJ*. > Am I missing a section? Yes I was: Section 3.4.4. Apologies to Doug. =========================================================================== Most of you people don't understand my point. You keep repeating that malloc() is supposed to return a value with all-the-alignment-requirements- of-any-type and that a subsequent cast to OBJ* won't change the-underlying- address-or-whatever. If I was implementing malloc() [I'm not, by the way.], I wouldn't do it any other way. All I'm arguing is that the standard does NOT require that. The only alignment requirement made for the value of malloc() is THAT IT IS SUITABLE FOR USE *AFTER CASTING*. If you don't believe me, read the standard again. Yes, this is maybe just an exercise in pedantry. Well-written standards should survive such exercises, though. Brendan McKay. bdm@anucsd.oz or bdm@anucsd.oz.au
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/19/89)
In article <1989Oct17.033415.16036@anucsd.oz> bdm@anucsd.oz (Brendan McKay) writes: >The only alignment requirement made for the value of malloc() is THAT IT >IS SUITABLE FOR USE *AFTER CASTING*. ... read the standard again. >Yes, this is maybe just an exercise in pedantry. Well-written standards >should survive such exercises, though. If you had constructive comments on the wording used in the proposed Standard, you should have made them during the public review phase when there would have been some chance that we would have performed some "wordsmithing" to clarify points that may have confused you. However, since we're being pedantic here, I'll point out that the Standard does NOT state what you capitalized. What is does say is, "The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or array of such objects in the space allocated ... The pointer returned points to the start (lowest byte address) of the allocated space." You appear to have jumped on the first sentence without considering its context. The second sentence I cited makes it clear that the pointer that malloc() returns is ITSELF already suitably aligned; no conversion is necessary to ensure that. The reason we say "may be assigned to a pointer..." is that the void* returned by malloc(), like any void*, itself is NOT a pointer to an "object" in the formal C sense, although it does point to the start of allocated space. P.S. As usual, this is not an official X3J11 response.
datanguay@watmath.waterloo.edu (David Adrien Tanguay) (10/20/89)
In article <11340@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
# However, since we're being pedantic here, I'll point out that the
# Standard does NOT state what you capitalized. What is does say is,
# "The pointer returned if the allocation succeeds is suitably aligned
# so that it may be assigned to a pointer to any type of object and
# then used to access such an object or array of such objects in the
# space allocated ... The pointer returned points to the start (lowest
# byte address) of the allocated space." You appear to have jumped on
# the first sentence without considering its context. The second
# sentence I cited makes it clear that the pointer that malloc()
# returns is ITSELF already suitably aligned; no conversion is
# necessary to ensure that.
I disagree about the second sentence. The first sentence says that the
allocated space must contain the desired object, but there's nothing that
says that the object must start at the beginning of the allocated space.
E.g., suppose sizeof(OBJ) == 8 and it needs even alignment (which is also
the worst case alignment on this fictional machine), and that an
assignment from void * to OBJ * causes the void * value to be advanced to
the next alignment boundary. malloc(OBJ) can then return address value 9,
with, say, 11 bytes following. The assignment to an OBJ *p gives p a value
of 10, which is suitably aligned. This satisfies the conditions of both
sentences, but p cannot be used as the argument to free or realloc.
David Tanguaygwyn@smoke.BRL.MIL (Doug Gwyn) (10/20/89)
In article <30538@watmath.waterloo.edu> datanguay@watmath.waterloo.edu (David A >I disagree about the second sentence. Again, you dropped context, this time from my posting instead of the Standard. I explained what the "assigned to" was all about. You're trying to give it meaning that was never intended, and by the "Could a reasonable person, in good faith, really misunderstand our intention?" test (which was one criterion for whether or not wording changes were called for during evaluation of public-review comments), I would have to say that the existing wording, taken in toto, is clear enough. I do know what you're saying, I just don't think it's a reasonable way to attempt to interpret the specifications. You have to work really hard to force your strange pointer-rounding implementation model to "fit" the specs, and even then it doesn't fit very well. It doesn't seem to be a real problem in the spec to me.
rhg@cpsolv.UUCP (Richard H. Gumpertz) (10/21/89)
In article <1989Oct17.033415.16036@anucsd.oz> bdm@anucsd.oz (Brendan McKay) writes: >Yes I was: Section 3.4.4. Apologies to Doug. I think this should be 3.3.4, not 3.4.4. -- ========================================================================== | Richard H. Gumpertz rhg@cpsolv.UUCP -or- ...!uunet!amgraf!cpsolv!rhg | | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 | ==========================================================================
datanguay@watmath.waterloo.edu (David Adrien Tanguay) (10/21/89)
In article <11363@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
# In article <30538@watmath.waterloo.edu> datanguay@watmath.waterloo.edu (David A
# >I disagree about the second sentence.
#
# Again, you dropped context, this time from my posting instead of the
# Standard. I explained what the "assigned to" was all about.
I did drop it, but it didn't explain any shortcoming in the "no you can't
free" argument: I actually used it to confirm my deductions while writing
the argument.
# You're
# trying to give it meaning that was never intended, and by the "Could
# a reasonable person, in good faith, really misunderstand our intention?"
# test (which was one criterion for whether or not wording changes were
# called for during evaluation of public-review comments), I would have
# to say that the existing wording, taken in toto, is clear enough.
Well, I agree with you here (which is why this is a pedantic argument).
It would take considerable bad faith for anybody to want to interpret
the standard in such a way to make free() useless. I still think it is
a reasonable interpretation of what the standard says, but it is clearly
not what the standard intends.
David Tanguay