regcmp()

The Beach Bum jfh at killer.UUCP
Sat Feb 20 08:49:54 AEST 1988


In article <15100006 at bucc2> brian at bucc2.UUCP writes:
>
>> > The problem is with what you are passing.  You are passing (char *)0 instead
>> > of (char *)NULL.  As I recall, Microport #defines NULL to be 0L instead of
>> > just 0.  This is an important difference.
>> 
>> Not if you cast it to "char *", it isn't!  Passing "(char *)0" is quite
>> sufficient, unless the compiler is horribly broken.
>
>  Tsk, tsk, tsk. This statment is true if sizeof(int) == sizeof(pointer).
>Not a good assumption to make, eh? I do a great deal of programming using
>Microsoft C 5.0 on IBM PEE CEE's. In large model, pointers are four bytes
>long. However, constant integer expessions are ints, and an int is only two
>bytes long.
>--
>  Brian Michael Wendt       UUCP: {cepu,ihnp4,uiucdcs,noao}!bradley!brian
>  Bradley University        ARPA: cepu!bradley!brian at seas.ucla.edu

Tsk, tsk, tsk, your Macrosludge compiler is not behaving correctly.  A
cast should return the same value (yes, I'll admit it, an rlvalue - don't
whip me any more) as if the casted value had been assigned to a temporary
variable of the given (type).

So, to give an example, if you write

func (char *arg)
{
	/* do stuff */
}

call_func (int x)
{
	func ((char *) x);
}

you should (_must_ in order to conform with K&R) have the same value
passed as if you had done

call_tfunc (int x)
{
	char	*p;

	p = (char *) x;
	func (p);
}

There is an _implied_ assignment of the expression to a temporary variable
which is of the same type as the cast.  The same thing holds true even
if the value being cast is not 0, although K&R warns that pointers created
in such a way may generate addressing exceptions when used.  For that
matter, the same thing hold true even if the type isn't (char *).  If
I write

double	func ()
{
	double d;

	d = (double) 5 / 2;
	return (d);
}

I had _better_ get 2.5, _not_ 2.0, which would be the case had the `double'
been ignored like MSC seems to be doing with (char *).

- John.
-- 
John F. Haugh II                  SNAIL:  HECI Exploration Co. Inc.
UUCP: ...!ihnp4!killer!jfh                11910 Greenville Ave, Suite 600
"You can't threaten us, we're             Dallas, TX. 75243
  the Oil Company!"                       (214) 231-0993 Ext 260



More information about the Comp.unix.questions mailing list