help on type compatibility?

[Ark]

Hello NG,

My Lint and my compiler disagree on whether this is valid code:

typedef int test_t(char *);
typedef int contest_t(const char *);
extern contest_t somefunction;
test_t *mypointer = somefunction;

I think the assignment is clean in what it does, but who cares? - What's
the verdict of the standard? (Both C90 and C99 resolutions are greatly
appreciated.)

Thank you,
- Ark

[aegis]

Ark wrote:

Hello NG,

My Lint and my compiler disagree on whether this is valid code:

typedef int test_t(char *);
typedef int contest_t(const char *);
extern contest_t somefunction;
test_t *mypointer = somefunction;

I think the assignment is clean in what it does, but who cares? - What's
the verdict of the standard? (Both C90 and C99 resolutions are greatly
appreciated.)

Part of one of the clauses of 3.5.4.3 states:
[1] "For two function types to be compatible, both
shall specify compatible return types. Moreover,
the parameter type lists, if both are present, shall
agree in the number of parameters and in use of
the ellipsis terminator; corresponding parameters
shall have compatible types."

So we need to ascertain whether or not their parameters
have compatible type:

'Is char * compatible with const char *?'

3.5.4.1 from one of its clauses, states:

"For two pointer types to be compatible, both
shall be identically qualified and both shall
be pointers to compatible types."

So their compatibility is predicated upon
whether or not they
1) point to compatible types
2) share the same qualifications

2 does not hold here, and therefore the
types are not compatible. The implication
is then that [1] does not hold.

--
aegis

[Ark]

aegis wrote:

Ark wrote:

Hello NG,

My Lint and my compiler disagree on whether this is valid code:

typedef int test_t(char *);
typedef int contest_t(const char *);
extern contest_t somefunction;
test_t *mypointer = somefunction;

I think the assignment is clean in what it does, but who cares? - What's
the verdict of the standard? (Both C90 and C99 resolutions are greatly
appreciated.)

Part of one of the clauses of 3.5.4.3 states:
[1] "For two function types to be compatible, both
shall specify compatible return types. Moreover,
the parameter type lists, if both are present, shall
agree in the number of parameters and in use of
the ellipsis terminator; corresponding parameters
shall have compatible types."

So we need to ascertain whether or not their parameters
have compatible type:

'Is char * compatible with const char *?'

3.5.4.1 from one of its clauses, states:

"For two pointer types to be compatible, both
shall be identically qualified and both shall
be pointers to compatible types."

So their compatibility is predicated upon
whether or not they
1) point to compatible types
2) share the same qualifications

2 does not hold here, and therefore the
types are not compatible. The implication
is then that [1] does not hold.

--
aegis

Thank you, aegis.
But...
Is it indeed that char * is not compatible with const char * ?
char * is unqualified pointer to char; const char * is unqualified
pointer to const char. So the question reduces to whether char is
compatible with const char, and I think it is... After all, we routinely
write
char c;
const char cc;
char *p;
const char *cp;
..............
c = cc;
cp = p;
I beg for further clarification...
Thank you,
Ark

[Robin Haigh]

"Ark" <ak*****@macroexpressions.com> wrote in message
news:E_******************************@comcast.com. ..

Hello NG,

My Lint and my compiler disagree on whether this is valid code:

typedef int test_t(char *);
typedef int contest_t(const char *);
extern contest_t somefunction;
test_t *mypointer = somefunction;

I think the assignment is clean in what it does, but who cares? - What's
the verdict of the standard? (Both C90 and C99 resolutions are greatly
appreciated.)

The assignment is legal because it's portable to convert a function pointer
to a different function pointer type and back again. (This can avoid the
need to use unions of function pointer types, which would be pointlessly
clumsy.)

But it's well worth a warning at this point, because no warning can be given
later if you then call the function through the pointer of the wrong type,
and that would produce undefined behaviour.

The problem is that the caller and the callee must agree implicitly on all
the details of how the function call is actually set up. The compiler makes
its own rules about that, and it's allowed to refer to the types of the
arguments, including qualifiers, if there's a prototype. So calling through
the wrong prototype can produce a mismatch in the calling sequence.

In this case it's likely that the undefined behaviour produced is to do the
right thing on all implementations, unless somebody knows different...

--
RSH

[pete]

Ark wrote:

char * is unqualified pointer to char; const char * is unqualified
pointer to const char.

No.

N869
6.2.5 Types
[#26]
Each
unqualified type has several qualified versions of its
type, corresponding to the combinations of one, two, or
all three of the const, volatile, and restrict qualifiers.

--
pete

[mark]

pete wrote:

Ark wrote:

char * is unqualified pointer to char; const char * is unqualified
pointer to const char.

No.

Yes.

[Chris Torek]

In article <PI********************@comcast.com>
Ark <ak*****@macroexpressions.com> wrote:

Is it indeed that char * is not compatible with const char *?
Yes, it is indeed not compatible.
[yet] we routinely write
char *p;
const char *cp;
.............
cp = p;
I beg for further clarification...

There is a special rule for assignment (including the implied
assignment from prototyped function calls) that relaxes the
constraints, so that you can do "cp = p", but not "p = cp".

This special rule does *not* apply to other cases, so:

char **pp;
...
pp = &cp;

requires a diagnostic.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Chris Torek]

>"Ark" <ak*****@macroexpressions.com> wrote in message

news:E_******************************@comcast.com ...

My Lint and my compiler disagree on whether this is valid code:

typedef int test_t(char *);
typedef int contest_t(const char *);
extern contest_t somefunction;
test_t *mypointer = somefunction;

In article <dt**********@newsg1.svr.pol.co.uk>
Robin Haigh <ec*****@leeds.ac.uk> wrote:The assignment is legal because ...
The assignment requires a diagnostic. GCC (some versions anyway)
just gets this wrong.

I think you are thinking of the version with casts:

test_t *mypointer = (test_t *)somefunction;

which does not require a diagnostic.
The problem is that the caller and the callee must agree implicitly on all
the details of how the function call is actually set up.

This, however, is correct.

The Standard has some wording that implies (or perhaps even "requires"
if you believe the footnotes, but the footnotes are "non-normative",
meaning an Evil Implementor can violate them without breaking the
rules) ... er, where was I? Oh yes: qualified and unqualified
variants of types are *supposed* to have the same underlying
representations, so one might simply assume that test_t and contest_t
are effectively interchangeable, and get away with it. It is quite
unlikely to break. Still, it is best not to skate on the thin ice.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[pete]

mark wrote:

pete wrote:

Ark wrote:

char * is unqualified pointer to char; const char * is unqualified
pointer to const char.

No.

Yes.

Idiot.

N869
6.2.5 Types
[#26]
Each
unqualified type has several qualified versions of its
type, corresponding to the combinations of one, two, or
all three of the const, volatile, and restrict qualifiers.

--
pete

[Jordan Abel]

On 2006-02-24, Chris Torek <no****@torek.net> wrote:

"Ark" <ak*****@macroexpressions.com> wrote in message
news:E_******************************@comcast.co m...

My Lint and my compiler disagree on whether this is valid code:

typedef int test_t(char *);
typedef int contest_t(const char *);
extern contest_t somefunction;
test_t *mypointer = somefunction;

In article <dt**********@newsg1.svr.pol.co.uk>
Robin Haigh <ec*****@leeds.ac.uk> wrote:

The assignment is legal because ...

The assignment requires a diagnostic. GCC (some versions anyway)
just gets this wrong.

I think you are thinking of the version with casts:

test_t *mypointer = (test_t *)somefunction;

which does not require a diagnostic.

The problem is that the caller and the callee must agree implicitly on all
the details of how the function call is actually set up.

This, however, is correct.

The Standard has some wording that implies (or perhaps even "requires"
if you believe the footnotes, but the footnotes are "non-normative",
meaning an Evil Implementor can violate them without breaking the
rules)

Even if the footnote is prescribing an interpretation of normative text,
rather than providing new rules?
... er, where was I? Oh yes: qualified and unqualified variants of
types are *supposed* to have the same underlying representations, so
one might simply assume that test_t and contest_t are effectively
interchangeable, and get away with it. It is quite unlikely to break.
Still, it is best not to skate on the thin ice.

[pete]

pete wrote:

mark wrote:

pete wrote:

Ark wrote:

> char * is unqualified pointer to char; const char * is unqualified
> pointer to const char.

No.

Yes.

Idiot.

After further consideration, I take it back.
Sorry.

--
pete

[kuyper]

aegis wrote:
....

'Is char * compatible with const char *?'

3.5.4.1 from one of its clauses, states:

"For two pointer types to be compatible, both
shall be identically qualified and both shall
be pointers to compatible types."

So their compatibility is predicated upon
whether or not they
1) point to compatible types
2) share the same qualifications

2 does not hold here, and therefore the
types are not compatible.
I don't follow that: neither pointer type is qualified, so item [2]
holds. Only the pointed-at types are differently qualified. The pointer
types themselves are both unqualified.
The implication is then that [1] does not hold.

I don't follow that implication. You're right that [1] doesn't hold.
However, that's because 6.7.3p9 requires the two types to have the same
qualification in order to be compatible, and "char" has different
qualification than "const char". It has nothing to do with the fact
that 3.5.4.1 requires the pointer types themselves to be identically
qualified.

[Douglas A. Gwyn]

Chris Torek wrote:

... so that you can do "cp = p", but not "p = cp".

Of course in practice you can accomplish the effect by
using a cast. At least that documents that something
unusual (and perhaps incorrect) is going on.

[Douglas A. Gwyn]

Chris Torek wrote:

... the footnotes are "non-normative",
meaning an Evil Implementor can violate them without breaking the
rules) ...

No that's not what it means. The footnotes (and examples)
are not meant to impose any additional requirements, but
they can and do clarify what is meant by otherwise puzzling
requirements in the normative portion of the text.

[Keith Thompson]

"Douglas A. Gwyn" <DA****@null.net> writes:

Chris Torek wrote:

... the footnotes are "non-normative",
meaning an Evil Implementor can violate them without breaking the
rules) ...

No that's not what it means. The footnotes (and examples)
are not meant to impose any additional requirements, but
they can and do clarify what is meant by otherwise puzzling
requirements in the normative portion of the text.

But they do not always do so perfectly.

For example, 6.2.5p26 says:

A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type.

and a footnote says:

The same representation and alignment requirements are meant to
imply interchangeability as arguments to functions, return values
from functions, and members of unions.

Without that footnote, an implementation that passed void* and char*
arguments in different registers (as some real implementations do for
integer and floating-point arguments) could be conforming; the types
would still have the same representation and alignment requirements.

There would be little reason (that I can think of) for an
implementation to pass char* and void* differently, but as a
programmer I wouldn't be able to assume that they weren't if I wanted
my code to be portable.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[kuyper]

Douglas A. Gwyn wrote:

Chris Torek wrote:

... the footnotes are "non-normative",
meaning an Evil Implementor can violate them without breaking the
rules) ...

No that's not what it means. The footnotes (and examples)
are not meant to impose any additional requirements,

The point is, that not only are they not meant to impose any additional
requirements, they CAN"T impose any additional requirements. A footnote
can guide us to the correct interpretation of the requirements, but if
a footnote claims that something is true which cannot be derived from
the normative text, that claim is simply false, and can therefore be
ignored.

[WaterWalk]

I'm sorry, but what does "typedef int test_t(char *)" mean?

int test_t(char *); //This is a function prototype
typedef int (*test_t)(char *); //This is a fuction pointer typedef

But,
typedef int test_t(char *); // I don't know what it is.

[pete]

WaterWalk wrote:

I'm sorry, but what does "typedef int test_t(char *)" mean?

int test_t(char *); //This is a function prototype

When you have a declaration
with a primary expression identifier,
and you write "typedef" in front of it,
what was the identifier in the declaration,
becomes a name for the type that it had.

That typedef is for a function type.

/* BEGIN new.c */

#include <stdio.h>

typedef int test_t(char *);

test_t test1, test2;

int main(void)
{
test1("Hello");
test1("World");
return 0;
}

int test1(char *a)
{
return puts(a);
}

int test2(char *a)
{
return puts(a);
}

/* END new.c */

--
pete

[pete]

pete wrote:

typedef int test_t(char *);

test_t test1, test2;

int main(void)
{
test1("Hello");
test1("World");

I intended that last line to be test2("World")
but it doesn't make much difference.

--
pete

[Ben Bacarisse]

On Fri, 24 Feb 2006 18:48:46 +0000, Chris Torek wrote:

In article <PI********************@comcast.com> Ark
<ak*****@macroexpressions.com> wrote:

Is it indeed that char * is not compatible with const char *?

Yes, it is indeed not compatible.

[yet] we routinely write
char *p;
const char *cp;
.............
cp = p;
I beg for further clarification...

There is a special rule for assignment (including the implied assignment
from prototyped function calls) that relaxes the constraints, so that you
can do "cp = p", but not "p = cp".

This special rule does *not* apply to other cases, so:

char **pp;
...
pp = &cp;

requires a diagnostic.

I some ways the more surprising example is that:

const char * const *pcp;
pcp = pp;

also requires a diagnostic. Surprising because this way round no
"const"ness is being lost.

--
Ben.

[Chris Torek]

[given cp as a variable of type "const char *" and p as one
of type "char *"]

On Fri, 24 Feb 2006 18:48:46 +0000, Chris Torek wrote:

There is a special rule for assignment ... so that you can
do "cp = p", but not "p = cp".

This special rule does *not* apply to other cases, so:

char **pp;
...
pp = &cp;

requires a diagnostic.

In article <pa***************************@bsb.me.uk>
Ben Bacarisse <be********@bsb.me.uk> wrote:I some ways the more surprising example is that:

const char * const *pcp;
pcp = pp;

also requires a diagnostic. Surprising because this way round no
"const"ness is being lost.

Indeed, and this "works right" in C++. I do not know why the C99
folks did not adopt the C++ "const" rules here.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Richard G. Riley]

On 2006-02-24, pete <pf*****@mindspring.com> wrote:

mark wrote:

pete wrote:

> Ark wrote:
>
> > char * is unqualified pointer to char; const char * is unqualified
> > pointer to const char.
>
> No.

Yes.

Idiot.

I think you are mistaken.

const char * is a pointer to const characters.

[lawrence.jones]

In comp.std.c Chris Torek <no****@torek.net> wrote:

Indeed, and this "works right" in C++. I do not know why the C99
folks did not adopt the C++ "const" rules here.

Because the C++ folks chose to describe their language in a way that
isn't compatible with the way the C language was described, making it
necessary to translate the rules rather than just copying them, and
because C99 added the "restrict" qualifier that wasn't handled by the
rules.

-Larry Jones

Some people just don't have inquisitive minds. -- Calvin

[pete]

Richard G. Riley wrote:

On 2006-02-24, pete <pf*****@mindspring.com> wrote:

mark wrote:

pete wrote:
> Ark wrote:
>
> > char * is unqualified pointer to char; const char * is unqualified
> > pointer to const char.
>
> No.

Yes.
Idiot.

I think you are mistaken.

I think so too.
const char * is a pointer to const characters.

--
pete

[WaterWalk]

pete wrote:

pete wrote:

typedef int test_t(char *);

test_t test1, test2;

int main(void)
{
test1("Hello");
test1("World");

I intended that last line to be test2("World")
but it doesn't make much difference.

--
pete

This is the first time I hear about "function type". Even in K&R, I
don't remember any mention of this term. Thanks, pete. I'll look for
more about this.

[David R Tribble]

Aegis wrote:

'Is char * compatible with const char *?'

3.5.4.1 from one of its clauses, states:

"For two pointer types to be compatible, both
shall be identically qualified and both shall
be pointers to compatible types."

So their compatibility is predicated upon
whether or not they
1) point to compatible types
2) share the same qualifications

2 does not hold here, and therefore the types are not compatible.

Kuyper wrote: I don't follow that: neither pointer type is qualified, so item [2]
holds. Only the pointed-at types are differently qualified. The pointer
types themselves are both unqualified.

I agree.

Ark's code in question was:
typedef int test_t(char *s);
typedef int contest_t(const char *cs);
extern contest_t somefunction;
test_t *mypointer = somefunction; // A

[A] is an error, because it is attempting to remove the 'const'
from from a pointed-to parameter type.

On the other hand, this should work:
extern contest_t otherfunc;
contest_t myotherptr = otherfunc; // B

because [b] is adding a 'const' qualifier to a pointed-to parameter
type, which IIRC is okay. In other words, parameter s is
assignment-compatible to parameter cs, so function pointer
otherfunc should be assignable to myotherfunc without needing
an explicit cast. (But I could be wrong.)

-drt

[Micah Cowan]

"David R Tribble" <da***@tribble.com> writes:

Aegis wrote:

'Is char * compatible with const char *?'

3.5.4.1 from one of its clauses, states:

"For two pointer types to be compatible, both
shall be identically qualified and both shall
be pointers to compatible types."

So their compatibility is predicated upon
whether or not they
1) point to compatible types
2) share the same qualifications

2 does not hold here, and therefore the types are not compatible.

Kuyper wrote:

I don't follow that: neither pointer type is qualified, so item [2]
holds. Only the pointed-at types are differently qualified. The pointer
types themselves are both unqualified.

I agree.

Ark's code in question was:
typedef int test_t(char *s);
typedef int contest_t(const char *cs);
extern contest_t somefunction;
test_t *mypointer = somefunction; // A

[A] is an error, because it is attempting to remove the 'const'
from from a pointed-to parameter type.

On the other hand, this should work:
extern contest_t otherfunc;

I'm assuming you meant:

extern test_t otherfunc;
contest_t myotherptr = otherfunc; // B

because [b] is adding a 'const' qualifier to a pointed-to parameter
type, which IIRC is okay. In other words, parameter s is
assignment-compatible to parameter cs, so function pointer
otherfunc should be assignable to myotherfunc without needing
an explicit cast. (But I could be wrong.)

Yeah, unfortunately you're wrong.

For two types to be compatible, they must be identically
qualified. For /assignment/ purposes, a special exemption was made for
pointers to differently-qualified types, but those pointers
themselves--and indeed, the pointed-two types as well--are not
compatible.

-Micah

[Dave Thompson]

On 23 Feb 2006 20:56:01 -0800, "aegis" <ae***@mad.scientist.com>
wrote:

Ark wrote:

Hello NG,

My Lint and my compiler disagree on whether this is valid code:

int (*) (char*) assigned int (*) (const char *)
Part of one of the clauses of 3.5.4.3 states: <snip>

(they're not compatible)

Right. And thus a diagnostic is required, and as for all required
diagnostics what if anything happens after that is up to the
implementation. And this doesn't change between C90/99.

Note however that T* and cv-T* are required to have the same
representation and alignment which according to a nonnormative
footnote is "intended" to allow interchangeability as arguments among
other cases. Although unlike signed-unsigned and char*-void* there is
not normative language for unprototyped and va_arg calls. Even so an
implementation would be quite perverse to break any of these.

- David.Thompson1 at worldnet.att.net

[Douglas A. Gwyn]

ku****@wizard.net wrote:

... if a footnote claims that something is true which cannot be derived from
the normative text, that claim is simply false, and can therefore be ignored.

No, footnotes cannot be ignored. Go back and pay more heed to
what I said upthread -- when it comes to understanding the scope
of certain requirements such as in the specific case being
discussed, what the total "truth" consists of might not be
apparent until *after* you take the footnote into account.
Note that the main text requirement uses a term that is not
fully and completely defined within the main text, but the
footnote tries to explain what is meant by the term. If you
ignore the footnote, then you cannot understand what is meant.

[kuyper]

Douglas A. Gwyn wrote:

ku****@wizard.net wrote:

... if a footnote claims that something is true which cannot be derived from
the normative text, that claim is simply false, and can therefore be ignored.

I said that badly - it shouldn't be ignored - the discrepancy should be
fixed, either by changing the normative text, or by changing the
footnote; possibly both. However, the portions of the footnote that
can't be derived from the normative text can't be used to judge whether
or not an implementation conforms to the standard. That's what
"normative" means.
No, footnotes cannot be ignored. Go back and pay more heed to
what I said upthread -- when it comes to understanding the scope
of certain requirements such as in the specific case being
discussed, what the total "truth" consists of might not be
apparent until *after* you take the footnote into account.

It might not be apparant, but once you know that it was intended, it
must be possible to go back to the normative text and see that it does
indeed say what it didn't apparantly say.

I know that there are meta-standards; standards which specify how
standards are to be created, written, and interpreted. I am sure that
there's an ISO standard somewhere that defines precisely what
"normative" means in the context of an ISO standard. I don't have a
copy of that standard, so I'm not sure what it says about this. It's
quite possible that "normative" has a meaning in ISO standards that is
consistent with what you say. However, if so, it's another example of
specialized jargon with a meaning quite different from it's ordinary
English meaning, and I personally would have recommended that a
different word be used.

To say that a statement is "normative" means that it defines a norm
against which something is to be judged. In the context of the
standard, I'd expect that the thing which is being judged is
conformance with the standard. If non-normative text says that
something is true, that can't be derived from the normative text, then
conformance of a particular implementation to the standard can't be
judged by whether or not that statement is true about that particular
implementation.

As the standard itself informs us (in a non-normative section), the
non-normative text is for information only. Using it for such
judgements would be using it for something more than information. When
it contains anything other than information, when it establishes
requirements not deriveable from normative text, then it is false
information, and should be treated as such.