Re: Type punning question
On Jun 19, 2:45 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Jun 18, 5:13 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Jun 17, 9:49 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* Travis Vitek:
[snippety]
C++ code would go like this (off the cuff) -- look ma,
no casts! :-)
struct RtInfo
{
short maxPriority;
char filler[32 - sizeof(short)];
};
struct PcInfo
{
int id;
char className[16];
RtInfo rtInfo;
};
int main ()
{
PcInfo pc;
// assume a call to priocntl() will initialize pc with
// something like this...
// pc.classname [0] = 'R';
// pc.classname [1] = 'T';
// pc.classname [2] = 0;
//if (-1L == priocntl (idtype_t(), id_t(), PC_GETCLINFO, &p=
c))
// return -1;
return (0 == pc.rtInfo.maxPriority);
}
Except, of course, that he can't redefine the types, since
they're part of a system API.
The above doesn't redefine the types.
It's passing an incorrect type to priocntl.
On the contrary, it's passing a correct type. :-)
No. Read the man page. The only correct type when the third
argument is PC_GETCLINFO is a pcinfo_t* (defined in
<sys/priocntl.h>) Anything else is undefined behavior.
Within priocntl, with the given arguments, the pointer passed
is necessarily treated as a pointer to a type that's
identically defined to this type, in order to store the result
there.
I'd suggest that you start by reading the specification of the
function. (Admittedly, it's overly complex, and it's not easy
to find the necessary information.) You can't pass anything
else, even if you think it happens to look the same. And you
don't even know the order of the elements in a pcinfo_t. All
the specification says is that there must be three, with types
id_t, char[PC_CLNMSZ] and int[PC_CLINFOSZ]. And in the return
value, whether pc_clinfo actually contains an rtinfo_t or
something else depends on the pc_clname field---which is set by
the function, not by the caller.
The posted code has obviously been extracted from something more
complex (since the issue was the casting, and not the interface
of priocntl). The actual code probably looked more like:
// ...
if ( priocntl( idtype_t(), id_t(), PC_GETCLINFO, &pc )
== -1 ) {
// handle error...
} else if ( strcmp( pc.pc_clname, "RT" ) == 0 ) {
// the funny cast, etc.
} else {
// this may or may not be expected, but must
// never the less be present. If we get here,
// pc.pc_clinfo contains some other type, and
// not an rtinfo_t.
}
It's in order to handle that last else branch that I suggested
that a clean interface should return a polymorphic type.
As far as the API is concerned you can just as well pass an
untyped char[] buffer, provided it is suitably aligned and of
suitable size.
That's not what the documentation says. You would probably get
away with it, but it's undefined behavior according to both the
C standard and Sun's documentation.
There's absolutely no way for the function to know that the
bytes it's storing into will be interpreted by using a direct
declaration of the expected type instead of pointer cast to
that pointee type: *there is no magic*.
But there's no way for you to know the type it's going to store
there before calling the function. That's *why* the field is
declared as a buffer, and not declared with the correct type.
What matters is that the calling code access the data via a
correct type, and the above type is correct.
That's undefined behavior.
I'm sorry, that's incorrect in this context.
You say it's not. The man page from Sun says it is. Who am I
to believe?
[...]
Yes. Which means that the compiler can't detect the
error---it's undefined behavior, rather than a required
compile time diagnostic. The specifications of the function
say that if the cmd argument (the third argument) is
PC_GETCLINFO (his case), he must pass a pcinfo_t* as fourth
argument. Your PcInfo is *not* a pcinfo_t, so passing its
address is undefined behavior.
I'm sorry, that's incorrect: the names do not matter.
According to the C and the C++ standards, they do. More
importantly, however, you haven't defined the struct in the same
way. In fact, you can't define the struct in the same way,
because you don't know how it is defined; the specifications of
the function don't provide that information.
Practically, of course, it's going to work
Yes. :-)
(because Posix requires all pointers to have the same size
and representation)
Yes but also no: if you're talking about pointer
representation then the guarantee that the code relies on is
the C++ one about pointers to class type, which stems from the
ability to declare pointers to types with unknown size (a.k.a.
"incomplete" types).
Yes. There's a lot more to it than that, and I probably
shouldn't have mentionned only the pointer issue. It's the if
that follows, of course, which is most important. (Formally,
both the C standard and Posix allow strict type checking on
varargs, which would mean that passing anything but the struct
defined in the appropriate header would fail. In practice, Sun
doesn't do such checking, and almost certainly won't in the
future.)
*IF* your PcInfo has exactly the same size and layout as the
pcinfo_t. But the size and layout of a pcinfo_t isn't
specified,
I'm sorry, that's incorrect: the size is specified, the layout
of the things used is specified,
Where? All the specification I have says is that a pcinfo_t
struct must have the following members:
id_t pc_cid ;
char pc_clname[ PC_CLNMSZ ] ;
int pc_clinfo[ PC_CLINFOSZ ] ;
I can't find anything that imposes an order; I can't find
anything which forbids additional members; I can't find anything
that specifies the values of PC_CLINFOSZ or PC_CLINFOSZ; and I
can't find anything which says that id_t is guaranteed to be an
int. (In fact, the reason id_t is used is precisely because it
isn't guaranteed to be an int.)
and that's all that matters -- there is no magic.
and in fact could easily change when e.g. moving from
32 bits to 64.
Porting code from 32-bit to 64-bit isn't a case of just
recompiling.
Sure it is. I do it all the time. I've got lots of code that
was developed in 32 bit mode, then moved to 64 bits (typically
in order to handle larger files), and I've never had to change a
line of code because of it.
However, there are just three relevant in-practice cases: (1)
the sizes of built-in types change, in which case all's
automatic, nothing to fix, at least if the symbolic size names
from the header are used instead of the example's direct
numbers, (2) member variable declaration order is rearranged,
which will be caught by any assert, but is of probability like
getting being hit by a wayward lame duck, (3) the
functionality of the API is changed, or the API is removed, or
whatever, fundamental change, in which case the code needs to
be fixed, perhaps reimplemented, anyway. Summing up, one is
not worse off. But one is better off.
The most likely change is that PC_CLINFOSZ (and possibly
PC_CLNMSZ, in order to ensure a stricter alignment of the
following field) will change. Or the type of id_t.
If you wanted to go the route you're suggesting (IMHO, it's more
trouble than it's worth), then you'd still have to define your
types more along the lines of:
struct RtInfo
{
short maxPriority ;
};
struct PcInfo
{
id_t id ;
char className[ PC_CLNMSZ ] ;
union {
RtInfo rtInfo ;
int forAlignment ;
char forSize[ PC_CLINFOSZ * sizeof( int ) ] ;
} ;
} ;
There's still a risque with regards to the order, or additional
members, but it's probably fairly small (although personally, I
don't like to count on anything that isn't guaranteed). But
between the union and the reinterpret_cast, what do you gain?
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34