Path: utzoo!censor!dybbuk!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!samsung!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpclscu!shankar
From: shankar@hpclscu.cup.hp.com (Shankar Unni)
Newsgroups: comp.lang.c++
Subject: Re: Re: the SUN way.. *&$^#%)
Message-ID: <58170039@hpclscu.cup.hp.com>
Date: 22 Jan 91 03:34:38 GMT
Article-I.D.: hpclscu.58170039
References: <1990Dec20.114821@roadster.bellcore.com>
Organization: Hewlett-Packard Calif. Language Lab
Lines: 25

Ron Guilmette writes in response to one of my earlier notes:

> +P.S. regarding the "laxness" of ANSI C compilers: many such compilers,
> +recognizing the need for such a usage, are deliberately permissive
> +on a mismatch of function pointer arguments, if the mismatch is between
> +a "T *" and a "void *".
> 
> Oh, yea?!?!?!  Name two!  I dare you!  Who makes these sloppy implementations?

Sorry, sloppy wording..

Let me restate that: what I meant was that few ANSI C implementations give
hard errors on such a mismatch. They must diagnose the mismatch in order to
conform to the letter of the standard, but individual decisions have to be
made as to what should be flagged with a warning (those things with
"reasonable interpretations"), and what with hard errors.

This thing is a usability issue, and as long as the compiler correctly
points out your constraint violations to you, it's a judgement call as to
what must be stomped on, and what must be warned about but "permitted" for
usability's sake.
-----
Shankar Unni                                   E-Mail: 
Hewlett-Packard California Language Lab.     Internet: shankar@hpda.hp.com
Phone : (408) 447-5797                           UUCP: ...!hplabs!hpda!shankar