[comp.unix.questions] regcmp

brian@bucc2.UUCP (02/18/88)

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

...............................................................................

  When the going gets weird, the weird turn pro.

  Brian Michael Wendt       UUCP: {cepu,ihnp4,uiucdcs,noao}!bradley!brian
  Bradley University        ARPA: cepu!bradley!brian@seas.ucla.edu
  (309) 691-5175            ICBM: 40 40' N  89 34' W

chris@trantor.umd.edu (Chris Torek) (02/19/88)

>>>The problem is with what you are passing.  You are passing (char *)0
>>>instead of (char *)NULL.

[(char *)0 and (char *)NULL are required to be the same!]

>>Not if you cast it to "char *", it isn't!  Passing "(char *)0" is quite
>>sufficient, unless the compiler is horribly broken.  [Guy Harris]

In article <15100006@bucc2> brian@bucc2.UUCP writes:
>  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.

NO!  NO NO NO NO NO   *grumble*

Constant integer expressions are indeed ints.  (char *)0 is not
a constant integer expression, it is a constant expression of type
`pointer to char'.

Incidentally, Microsoft's definition of NULL as 0L is technically
legal, but is a bad idea.  It covers up code bugs in large model,
but they still show in mixed model code.

Once again:

	(char *)0
	(char *)0L
	(char *)NULL

are all identical in both value and type.  `0' is a proper nil
pointer of any type as long as it is in a context that coerces it
to a pointer.  Assignment, comparison, and casts provide context;
function calls do not[*].  It is that simple.

-----
[*] except when a prototype is in scope
-- 
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
(hiding out on trantor.umd.edu until mimsy is reassembled in its new home)
Domain: chris@mimsy.umd.edu		Path: not easily reachable

gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/19/88)

In article <15100006@bucc2> brian@bucc2.UUCP writes:
>> 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).

That statement was true regardless of the various object sizes.
(char *)0 has the right size.

jfh@killer.UUCP (The Beach Bum) (02/20/88)

In article <15100006@bucc2> brian@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@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

richard@aiva.ed.ac.uk (Richard Tobin) (02/23/88)

In article <15100006@bucc2> brian@bucc2.UUCP writes:
>> 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).

It certainly is.  It's also true if sizeof(int) != sizeof(pointer).

The way you get a null character pointer is by casting 0 to (char *).
If a compiler doesn't take (char *)0 to be a null character pointer,
it's broken, regardless of the length of pointers.  That's just the way
it is.

Casting 0 to (char *) is *NOT* defined to pretend that zero bit-pattern is
a pointer, it's defined to to *convert* 0.  The resulting bit pattern can
be anything at all (it's often zero).  All that matters is that it's
always the same, and that no object has it as its address.

-- Richard
-- 
Richard Tobin,                         JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,             ARPA:  R.Tobin%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.                  UUCP:  ...!ukc!ed.ac.uk!R.Tobin

fox@alice.marlow.reuters.co.uk (Paul Fox) (03/04/88)

In article <15100006@bucc2> brian@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).

Well, (char *) 0 and (char *) 0L are the SAME. Looks like the compiler
is broken. 
----------------------
     //        o      All opinions are my own.
   (O)        ( )     The powers that be ...
  /    \_____( )
 o  \         |
    /\____\__/      
  _/_/   _/_/         UUCP:     fox@alice.marlow.reuters.co.uk