Re: Supporting byte-addressability on word-addressed hardware

>>>[Pointer representations for GNU CC]


>David Keppel <pardo@cs.washington.edu> wrote:
>>[This fails sometimes.]
>>
>> int *p = malloc (sizeof(int));
>> free (p);
>>
>>[Correct: cast `p' to a `char *' before passing it to `free'.]


In 95-07-087 tl@ae.chalmers.se (Torbj|rn Lindgren) writes:
>[Works fine if you define `free' correctly.]


Good standard libraries fix the above but not the general problem. If
there are different formats for ``pointer to x'' and ``pointer to y''
then any code that relies on implicit casts at procedure calls will
fail without prototyped declarations (and the older declaration style,
``extern int foo()'' is not a prototype).


Code that relies on implied casts in the absence of prototypes *is*
technically broken. However, there's lots of code like that, and since
most machines use uniform pointer formats, even code that has been
widely used is all too likely to contain such errors. You can fix some
problems by providing prototypes in the standard libraries, but you
can't generally fix program bugs except by forcing your customers to
rewrite their code.


You, the compiler writer/vendor, need to decide if the benefits from
using mixed pointer formats outweighs the burden that you place on your
customers. Some customers only use ANSI C and won't care; others spend
a lot of time compiling dusty decks and will scream.


To summarize: some programs have bugs that are exposed when run on a
machine that uses several pointer formats. The three choices are
    (1) Use one pointer format
    (2) Rewrite the buggy programs
    (3) Don't support them
As I recall, the original poster asked if mixing pointer formats would
cause any problems. If supporting old code (``dusty disks'') is one of
your goals, then yes, mixing pointer formats can cause problems.


;-D on ( The bug is in the eye of the beholder ) Pardo
--

Return to the comp.compilers page.
Search the comp.compilers archives again.