Type punning question

[James Kanze]

* James Kanze:

* James Kanze:
* James Kanze:
* 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, &pc))
// 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.

First, Undefined Behavior is a term used in the C++ standard
for certain aspects of the C++ language, it does not apply
here and is completely meaningless here, unless you want to
also describe the OP's call as Undefined Behavior.

Undefined behavior is a term defined in the C and C++ standards.
And it very definitely applies here. The specification of
priocntl says clearly that if the third argument is
PC_GETCLINFO, then the forth must have type pcinfo_t*. That's
the specification of the function. And since nothing is
specified as to what happens if you don't respect the
requirement, not respecting it is undefined behavior.

I'm using the term "undefined behavior", as defined in the C and
the C++ standards, because it is a term I presume readers of
this group understand, and are familiar with. And its meaning
describes the exact situation we find here: a specification for
a function contains a requirement, and doesn't specify what
occurs if that requirement is violated.

Come to think of it you have done exactly that, described the
OP's code as formally UB. So you're technically contradicting
yourself by implying that the code above is somehow C++ UB
while the OP's code isn't.

You must have misread my postings. I specifically said that the
op's code wasn't undefined behavior, since he doesn't violate
any of the requirements of the C++ standard.

I am aware of how that technical point, the point of whether
there is real meaning at all, does matter when speaking to me,
and doesn't matter in FUDding the general audience.

Second, if you try to use some more meaningful non-standard
meaning of "Undefined Behavior", sort of, "it won't
necessarily work", then you have yourself stated that of
course it will work, again a self-contradiction (there can't
be anything undefined about something that clearly will and
does work).

Again, you're not reading what you're replying to. I said it
will probably work *IF*... After the if were a couple of
conditions which you can't know whether you've met or not. In
other words, it's typical undefined behavior: it might seem to
work some of the time, but you really don't know.

Summing up so far, for both possible intended meanings of UB
above you have engaged in self-contradiction, and the only
conclusion is that you're not talking to me, because you know
that I don't suffer idiot statements gladly (not my own, and
not yours), but that you are instead trying to FUD the general
audience with some emotive techno-babble.

Summing up so far, you haven't read the postings you're
responding to.

It seems that you fail to understand simple logic and examples
that work?

And want to muddy the waters, yes?

By referring to the specification of the function? By basing my
reasoning on what the function guarantees, and what it is
documented to requires?

I snip the rest of your article: I do not care to engage in
"speaking to the audience": this issue is extremely simple and
clear cut, and you have presented no technical point but a lot
of FUD,

The issue is extremely simple and clear cut. The specification
(contract) of the function states a number of specific
requirements. Your code fails to respect them, so your code has
undefined behavior. You may choose to ignore the specification
of the function, or to pretend it is something else, but that
doesn't change the facts.

 

[Alf P. Steinbach]

* James Kanze:

* James Kanze:

* James Kanze:
* James Kanze:
* 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, &pc))
// 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.

First, Undefined Behavior is a term used in the C++ standard
for certain aspects of the C++ language, it does not apply
here and is completely meaningless here, unless you want to
also describe the OP's call as Undefined Behavior.

Undefined behavior is a term defined in the C and C++ standards.
And it very definitely applies here. The specification of
priocntl says clearly that if the third argument is
PC_GETCLINFO, then the forth must have type pcinfo_t*. That's
the specification of the function. And since nothing is
specified as to what happens if you don't respect the
requirement, not respecting it is undefined behavior.

I'm using the term "undefined behavior", as defined in the C and
the C++ standards, because it is a term I presume readers of
this group understand, and are familiar with. And its meaning
describes the exact situation we find here: a specification for
a function contains a requirement, and doesn't specify what
occurs if that requirement is violated.

The standards don't say any such thing. Your statement is in that respect not
merely wrong, because you know that it's wrong and you say it anyway. It also
appears to be FUD-like intentional bullshit when you say that a requirement has
been violated, but perhaps you really don't understand it (that's very hard to
believe though, and in light of your previous 2 postings I'm sure it's BS FUD).

- Alf