Re: Supporting byte-addressability on word-addressed hardware

pardo@cs.washington.edu (David Keppel)
Wed, 19 Jul 1995 18:08:26 GMT

          From comp.compilers

Related articles
Supporting byte-addressability on word-addressed hardware lehotsky@tiac.net (1995-06-27)
Re: Supporting byte-addressability on word-addressed hardware simmons@bnr.ca (steve (s.s.) simmons) (1995-06-28)
Re: Supporting byte-addressability on word-addressed hardware markt@harlequin.co.uk (1995-07-04)
Re: Supporting byte-addressability on word-addressed hardware pardo@cs.washington.edu (1995-07-05)
Re: Supporting byte-addressability on word-addressed hardware bob@tera.com (1995-07-06)
Re: Supporting byte-addressability on word-addressed hardware mfx@cs.tu-berlin.de (1995-07-06)
Re: Supporting byte-addressability on word-addressed hardware tl@ae.chalmers.se (1995-07-12)
Re: Supporting byte-addressability on word-addressed hardware pardo@cs.washington.edu (1995-07-19)
Re: Supporting byte-addressability on word-addressed hardware meissner@cygnus.com (Michael Meissner) (1995-07-20)
| List of all articles for this month |

Newsgroups: gnu.gcc.help,comp.compilers
From: pardo@cs.washington.edu (David Keppel)
Keywords: GCC, architecture
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: 95-06-081 95-07-087
Date: Wed, 19 Jul 1995 18:08:26 GMT

>>>[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
--


Post a followup to this message

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