[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 2nd call: binary incompatibility



   Date: Wed, 17 Sep 1997 02:48:25 +0000 (/etc/localtime)
   From: Cristian Gafton <gafton@redhat.com>

   And how would you test that out ? If you do:
	   if (firstarg->magic == magicnumber)
		   blah;
   you already have a race. How do you de-reference a pointer which might not
   be a pointer ?

Obviously, you need to make some hueristic checks to see if it "looks
like" a pointer.  Hey, I said this was a kludge.....  it'd probably be a
temporary thing while we got all of our applications converted.

   It's hard to tell wether the first arg is a *pamh after 'if it's not a
   small number', because on some platforms byte ordering can cause some
   problems...

Byte ordering won't be a problem, since the PAM library emits the error
codes, and error codes are a local host issue.  So the PAM library
implementation will know exactly what error numbers would be used.

We might have problems on platforms where the size of a pointer is
different from the size of an int, and the compiler plays special
packing games in its function calling conventions.  i.e., suppose
pointers are 64 bits, and integers are 32 bits.  A clever compiler might
establish a calling convetion where if you have two integer arguments,
they are sent in the top and bottom half of the 64 bit register.  

Fortunately, most platforms don't play this game, and I'm fairly sure
none of the currently support Linux platforms try to do anything quite
this ugly.  (The reason why is that separating out the two arguments
gets expensive.)

So under the alpha, suppose the calling application has this:

extern char *pam_strerror(int status)

....
	str = pam_strerror(3)
....

and the library has this:

char *pam_strerror(pam_handle_t *pamh, int status)
{
	int old_status;

	old_status = (int) pamh;
	...
}

I'm pretty sure that old_status will be 3.  (And conveniently, on the
Alpha's --- at least under Digital Unix; ---, all pointers have the
property that the high 32 bits are non-zero, so you *know* that an
integer which has been cast into a pointer will always result in a
invalid pointer.)

   Better off cut from the early stage than try to maintain a workaround that
   will be broken at some point in the near future...

If we do this kind of workaround, it should obviously be under an
#ifdef.  However, for some folks such as RedHat, where customers can get
annoyed with things aren't backwards compatible, it might be a really
nice feature to have.

Remember, if you want to seem to be professional, you have to be
backwards compatible.  Microsoft understands this; it may result in code
which is ugly for a while, but it's a real prequisite for general
success outside of the hacker community.

						- Ted



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []