[2247] in Kerberos_V5_Development
Re: Function pointers with krb5_{calculate,verify}_checksum
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Wed Feb 19 17:53:53 1997
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: krbdev@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 19 Feb 1997 17:41:57 -0500
In-Reply-To: Ken Hornstein's message of Wed, 19 Feb 1997 17:22:26 -0500
Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:
> "Interesting". However, I don't think the _function_ call is failing,
> on second glance .... I think it's the test to see if the function pointer
> is NULL. So what is the value of **f under these rules?
Yes. If I recall correctly, and older version of krb5_x we used had
this problem; the compiler does try to do the indirection, and botches
it.
> Can you quote a more specific part of the ANSI C standard? If I can go
> to the vendor and say, "Section X of the standard says you're wrong", it will
> bolster my argument :-)
Try 3.2.2.1, paragraph 4:
A _function designator_ is an expression that has function
type. Except when it is the operand of the _sizeof_ operator
or the unary & operator, a function designator with type
"function returning _type_" is converted to an expression that
has type "pointer to function returning _type_".
Thus, in "if (*f) ...", when "f" is a function pointer, "*f" has type
"function returning X", and thus is automatically converted back to
the address expression. So it should be testing the address, not the
bytes stored there.
> Fair enough. But it still seems to me that this code is inconsistant with
> the other uses of the krb5_x macro.
Yup.
Ken
P.S. Just saw Mark's mail. From my reading of the spec, Ted's
reasoning relative to ANSI C is wrong, but the change is necessary
anyways because of this compiler bug.
