«

Not sure if this is the right place or OT.
One of the Parasoft coding guidelines (which I am using for current project) is
"Do not cast pointers to functions to pointers to primitive types [CODSTA-09-3]"

EXAMPLE(from parasoft document):
void Foo(char *ptrC)
{
*ptrC = 0;
return;
}

void f()
{
void *ptrV = 0;
void (*funPtr) (char*) = 0;
funPtr = &Foo;
ptrV = (void*)funPtr; // Violation of the rule and raise error
return;
}

I can see why it is a bad idea not to write code this way.
But can any one explain where this kind of code is useful?
(imo, to be a guideline it must have been used/misused a lot)
Where casting a function pointer to primitive type makes sense?
Sorry if this is too silly, my mind seems to have hit a wall today.

Regards
Ajay

On 09/ 3/12 08:50 PM, ajaybgr wrote:
> Not sure if this is the right place or OT.
> One of the Parasoft coding guidelines (which I am using for current project) is
> "Do not cast pointers to functions to pointers to primitive types [CODSTA-09-3]"
>
> EXAMPLE(from parasoft document):
> void Foo(char *ptrC)
> {
> *ptrC = 0;
> return;
> }
>
> void f()
> {
> void *ptrV = 0;
> void (*funPtr) (char*) = 0;
> funPtr =&Foo;
> ptrV = (void*)funPtr; // Violation of the rule and raise error
> return;
> }
>
> I can see why it is a bad idea not to write code this way.
> But can any one explain where this kind of code is useful?

In a bad dream...

> (imo, to be a guideline it must have been used/misused a lot)
> Where casting a function pointer to primitive type makes sense?

An awful lot of bad C code has been has been hacked together in the past
30+ years!

--
Ian Collins

On Sep 3, 9:50*am, ajaybgr <ajay....@gmail.com> wrote:

> Not sure if this is the right place or OT.
> One of the Parasoft coding guidelines (which I am using for current project) is
> "Do not cast pointers to functions to pointers to primitive types [CODSTA-09-3]"
>
> EXAMPLE(from parasoft document):
> void Foo(char *ptrC)
> {
> * * *ptrC = 0;
> * * return;
>
> }
>
> void f()
> {
> * * void *ptrV = 0;
> * * void (*funPtr) (char*) = 0;
> * * funPtr = &Foo;
> * * ptrV = (void*)funPtr; // Violation of the rule and raise error
> * * return;
>
> }
>
> I can see why it is a bad idea not to write code this way.
> But can any one explain where this kind of code is useful?
> (imo, to be a guideline it must have been used/misused a lot)
> Where casting a function pointer to primitive type makes sense?
> Sorry if this is too silly, my mind seems to have hit a wall today.

it probably arises from the misconception that "void* is a pointer to
anything" since on most architectures object pointers and functions
pointers are "just addreses" you can get away with it a lot of the
time. Yes it is a bad idea.

ajaybgr <> writes:

> Not sure if this is the right place or OT. One of the Parasoft coding
> guidelines (which I am using for current project) is "Do not cast
> pointers to functions to pointers to primitive types [CODSTA-09-3]"
>
> EXAMPLE(from parasoft document):
> void Foo(char *ptrC)
> {
> *ptrC = 0;
> return;
> }
>
> void f()
> {
> void *ptrV = 0;
> void (*funPtr) (char*) = 0;
> funPtr = &Foo;
> ptrV = (void*)funPtr; // Violation of the rule and raise error
> return;
> }
>
> I can see why it is a bad idea not to write code this way.
> But can any one explain where this kind of code is useful?
> (imo, to be a guideline it must have been used/misused a lot)
> Where casting a function pointer to primitive type makes sense?

Like others, I can't really answer your question except to add that
these sorts of conversion are undefined according to the definition of
C. It's possible, then, that the rule is in your coding guidelines, not
because it's so tempting, but simply because it's a no-so-well-known
rule of the language.

--
Ben.

On 09/03/2012 04:50 AM, ajaybgr wrote:
> Not sure if this is the right place or OT.
> One of the Parasoft coding guidelines (which I am using for current project) is
> "Do not cast pointers to functions to pointers to primitive types [CODSTA-09-3]"
>
> EXAMPLE(from parasoft document):
> void Foo(char *ptrC)
> {
> *ptrC = 0;
> return;
> }
>
> void f()
> {
> void *ptrV = 0;
> void (*funPtr) (char*) = 0;
> funPtr = &Foo;
> ptrV = (void*)funPtr; // Violation of the rule and raise error
> return;
> }
>
> I can see why it is a bad idea not to write code this way.
> But can any one explain where this kind of code is useful?
> (imo, to be a guideline it must have been used/misused a lot)
> Where casting a function pointer to primitive type makes sense?
> Sorry if this is too silly, my mind seems to have hit a wall today.

There are real platforms, in common use, where the behavior of such
code, while not defined by the C standard, is defined by some other
standard, and there's a fair amount of code written for those platforms
which actually relies upon that assumption. This produces the
unjustified but understandable belief that the technique will work
everywhere.

Example: the dlsym() function is specified by the X-open standard to
take a void* argument which can be either a pointer to an object or a
pointer to a function. The Rationale for that function notes;

> ... the ISO C standard does not require that an object of type void * can hold a pointer to a function. Implementations supporting the XSI extension, however, do require that an object of type void * can hold a pointer to a function. The result of converting a pointer to a function into a pointer to another data type (except void *) is still undefined, however. Note that compilers conforming to the ISO C standard are required to generate a warning if a conversion from a void * pointer to a function pointer is attempted ...
> Due to the problem noted here, a future version may either add a new function to return function pointers, or the current interface may be deprecated in favor of two new functions: one that returns data pointers and the other that returns function pointers.
--
James Kuyper

James Kuyper <> writes:
[...]
> Example: the dlsym() function is specified by the X-open standard to
> take a void* argument which can be either a pointer to an object or a
> pointer to a function. The Rationale for that function notes;
>
[...]
>> Note that compilers conforming to the ISO C standard are required to
>> generate a warning if a conversion from a void * pointer to a
>> function pointer is attempted.
[...]

I don't believe that's correct. The behavior of converting a void*
pointer to a function pointer is not defined, but as far as I can tell
it doesn't violate any constraint.

A concrete example:

int obj;
void *vp = &obj;
void (*fp)(void) = (void (*)(void))vp;

The constraints on a cast operator are described in N1570 6.5.4.
The cast in the above code doesn't violate any of them. (Perhaps
there *should* be such a constraint.)

Or am I missing something?

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 09/03/2012 04:21 PM, Keith Thompson wrote:
> James Kuyper <> writes:
> [...]
>> Example: the dlsym() function is specified by the X-open standard to
>> take a void* argument which can be either a pointer to an object or a
>> pointer to a function. The Rationale for that function notes;
>>
> [...]
>>> Note that compilers conforming to the ISO C standard are required to
>>> generate a warning if a conversion from a void * pointer to a
>>> function pointer is attempted.
> [...]
>
> I don't believe that's correct. The behavior of converting a void*
> pointer to a function pointer is not defined, but as far as I can tell
> it doesn't violate any constraint.
>
> A concrete example:
>
> int obj;
> void *vp = &obj;
> void (*fp)(void) = (void (*)(void))vp;
>
> The constraints on a cast operator are described in N1570 6.5.4.
> The cast in the above code doesn't violate any of them. (Perhaps
> there *should* be such a constraint.)
>
> Or am I missing something?

It's possible that they're referring to implicit conversion, rather than
one using a cast.
--
James Kuyper

James Kuyper <> writes:
> On 09/03/2012 04:21 PM, Keith Thompson wrote:
>> James Kuyper <> writes:
>> [...]
>>> Example: the dlsym() function is specified by the X-open standard to
>>> take a void* argument which can be either a pointer to an object or a
>>> pointer to a function. The Rationale for that function notes;
>>>
>> [...]
>>>> Note that compilers conforming to the ISO C standard are required to
>>>> generate a warning if a conversion from a void * pointer to a
>>>> function pointer is attempted.
>> [...]
>>
>> I don't believe that's correct. The behavior of converting a void*
>> pointer to a function pointer is not defined, but as far as I can tell
>> it doesn't violate any constraint.
[...]
>
> It's possible that they're referring to implicit conversion, rather than
> one using a cast.

It's possible, but if so they phrased it poorly.

Note that gcc also appears to get this wrong (assuming my interpretation
is correct). With "-std=c11 -pedantic", gcc 4.7 complains:

warning: ISO C forbids conversion of object pointer to function pointer type [-pedantic]

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <>,
Keith Thompson <kst-> wrote:
>James Kuyper <> writes:
>> On 09/03/2012 04:21 PM, Keith Thompson wrote:
>>> James Kuyper <> writes:
>>> [...]
>>>> Example: the dlsym() function is specified by the X-open standard to
>>>> take a void* argument which can be either a pointer to an object or a
>>>> pointer to a function. The Rationale for that function notes;
>>>>
>>> [...]
>>>>> Note that compilers conforming to the ISO C standard are required to
>>>>> generate a warning if a conversion from a void * pointer to a
>>>>> function pointer is attempted.
>>> [...]
>>>
>>> I don't believe that's correct. The behavior of converting a void*
>>> pointer to a function pointer is not defined, but as far as I can tell
>>> it doesn't violate any constraint.
>[...]
>>
>> It's possible that they're referring to implicit conversion, rather than
>> one using a cast.
>
>It's possible, but if so they phrased it poorly.

Any idiot should be able to read that and know without being told that using
a cast will get rid of the warning. Casts do that. It's obvious.

--
Alan Curry

On 03/09/2012 22:21, Keith Thompson wrote:
[..]
> A concrete example:
>
> int obj;
> void *vp = &obj;
> void (*fp)(void) = (void (*)(void))vp;
>
> The constraints on a cast operator are described in N1570 6.5.4.
> The cast in the above code doesn't violate any of them. (Perhaps
> there*should* be such a constraint.)
>
> Or am I missing something?

My understanding is that there is not such a constraint to allow
such casts as a "common extension", N1570 J.5.7:

A pointer to an object or to void may be cast to a pointer
to a function, allowing data to be invoked as a function (6.5.4).

A pointer to a function may be cast to a pointer to an object or to
void, allowing a function to be inspected or modified (for example,
by a debugger) (6.5.4).

If that cast violated a constraint any implementation with such
extension would be nonconforming. I only see a warning with gcc
however when `-pedantic' is enabled.

--
Vincenzo Mercuri