Xref: utzoo comp.std.c:1867 comp.lang.c:23004
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: commom malloc/free practice breaks standard - author strikes back
Message-ID: <11334@smoke.BRL.MIL>
Date: 19 Oct 89 09:45:56 GMT
References: <1989Oct16.111059.3840@anucsd.oz> <416@cpsolv.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 33

In article <416@cpsolv.UUCP> rhg@cpsolv.uucp (Richard H. Gumpertz) writes:
>4) If the implementor of malloc wants to return odd pointers, knowing that
>type-casting will round up (also UNUSUAL but legal), ...

NO, it is NOT legal!  Sheesh.

>No sane compiler (actually, library) implementor should implement things that
>don't work with common coding style.

This is a useless criterion.  Some common coding style is ERRONEOUS.
A C implementor should implement the language specified in the Standard,
providing whatever additional value seems appropriate.  A programmer
should avoid asking of an implementation things that are not guaranteed
by the language standard.  That is the "treaty point" that makes the
Standard useful.

>5) The appropriate changes to the standard would be in the sections on free
>and realloc.  In particular, 4.10.3.2 should be expanded to indicate not just
>"a pointer earlier returned by the calloc, malloc, or realloc" but rather a
>pointer that may have been cast using "(void *) (any-type *)" from the value
>returned by calloc, malloc, or realloc.  Similar changes to 4.10.3.4.   Note
>that this change is really NEEDED in the standard anyway to allow the end-user
>to use the doubly-cast value for free rather than the original value.

Wrong, wrong, wrong.  The Standard already says what was intended in
this regard.  It did NOT intend for your interpretation to be applied.
In fact, what you're asking for can be deduced as a special case from
the existing specifications in the Standard; no additional wording is
necessary to enforce this constraint.

>Hence, I again recommend against the unusual rounding implementation.

I recommend against it because it is not standard conforming.