CW10 assignment, void*, func ptr warnings...

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

hp - 14 Nov 2005 19:57 GMT

Starting my CW9.4 to CW10 migration. So far I am unsuccessful in
compiling the simplest of
projects. Sigh.

1) Warning : possible unwanted assignment
FileUtils.cc line 768 if (filePathStart && (len =
strlen(filePathStart)))

the old trick of parenthesizing the expr no longer seems to work?

2) Warning : illegal explicit conversion from 'bool (*)(bool)' to 'void
*'

have some code that was "forced" to move to a void* for a func ptr,
and the compiler wont tolerate this? It also emits a similar warning
when going from the void* back to a func ptr cast. Why?

3) errors about func signatures; eg, when calling NewUserItemUPP(), I
get errors about the func ptr:

Error : function call 'NewUserItemUPP({lval} pascal void
(OpaqueDialogPtr *, short))' does not match
'NewUserItemUPP(pascal extern "C" void (*)(OpaqueDialogPtr *, short))'

Must I now declare them with extern "C" ??

Gee. These kinds of issues are really not helpful when one has real
problems to solve..

-harry

Reply to this Message

Ben Artin - 14 Nov 2005 20:24 GMT

> 2) Warning : illegal explicit conversion from 'bool (*)(bool)' to 'void
> *'
>
> have some code that was "forced" to move to a void* for a func ptr,
> and the compiler wont tolerate this? It also emits a similar warning
> when going from the void* back to a func ptr cast. Why?

Because casting a function pointer to void* invokes undefined (or
implementation-defined, I forget) behavior, according to the language standard.

Ben

Signature

If this message helped you, consider buying an item
from my wish list: <http://artins.org/ben/wishlist>

I changed my name: <http://periodic-kingdom.org/People/NameChange.php>

Reply to this Message

Steve - 14 Nov 2005 22:25 GMT

On 14/11/05 19:57, in article
1131998241.038175.14010@g44g2000cwa.googlegroups.com, "hp" <harry@plate.org>
wrote:

> Starting my CW9.4 to CW10 migration. So far I am unsuccessful in
> compiling the simplest of
[quoted text clipped - 5 lines]
>
> the old trick of parenthesizing the expr no longer seems to work?

It will still work, it's just that using = instead == is such a common
mistake, the compiler is just being helpful. You can ignore the warning.

Pointers to functions aren't necessarily the same size as void*. This is
dangerous. However, the compiler is tolerating it (albeit under protest!) -
its only a warning.

BTW, I posted something a couple of years ago that highlighted this problem:

<http://groups.google.co.uk/group/comp.sys.mac.programmer.codewarrior/browse
_thread/thread/6b7e054fd979f24c/75b68355b97706f0?tvc=2&q=_Inhibit_Container_
Optimization#75b68355b97706f0>

I wonder - has it been fixed in CW10?

Signature

Regards,
Steve

"...which means he created the heaven and the earth... in the DARK! How good
is that?"

Reply to this Message

Gregory Weston - 14 Nov 2005 22:39 GMT

> On 14/11/05 19:57, in article
> 1131998241.038175.14010@g44g2000cwa.googlegroups.com, "hp" <harry@plate.org>
[quoted text clipped - 12 lines]
> It will still work, it's just that using = instead == is such a common
> mistake, the compiler is just being helpful. You can ignore the warning.

Well, no. What he's saying, and illustrating, is that it doesn't work.
He wasn't using the parens to make it legal, because there was nothing
illegal about it. The intention of the parens is to suppress the warning
and it's (apparently) no longer doing that.

But to the OP - I believe the idiom is to insert a superfluous set of
parens and, if I recall my precedence rules correctly, the set you've
got there isn't. See if this works:

if (filePathStart && ((len = strlen(filePathStart))))

G

Signature

Goal 2005: Convincing James Hetfield to cover the Strawberry Shortcake
"Are You Berry Berry Happy?" song.

Reply to this Message

Carl Barron - 15 Nov 2005 00:52 GMT

> On 14/11/05 19:57, in article
> 1131998241.038175.14010@g44g2000cwa.googlegroups.com, "hp" <harry@plate.org>
[quoted text clipped - 32 lines]
>
> I wonder - has it been fixed in CW10?

// helloworld.1.cp
#include <cstring>
#include <iostream>

int main()
{
char *p = "test";
long len;
if(p && ((len=std::strlen(p)))) // produce warning
std::cout << len << ' ';
std::cout << "done\n";

}

// helloworld.2.cp
#include <cstring>
#include <iostream>

int main()
{
char *p = "test";
long len;
if(p && ((len=std::strlen(p))!=0)) // no warning
std::cout << len << ' ';
std::cout << "done\n";

}

further comparing the disassemblys of helloworld.[12].cp
shows only an insignifigant changes a modification date
and the source code line. the code is identical.

Reply to this Message

larry@skytag.com - 15 Nov 2005 04:11 GMT

> Starting my CW9.4 to CW10 migration. So far I am unsuccessful in
> compiling the simplest of projects. Sigh.

Wow. I had only one or two minor issues porting my project of over 700
files.

> 1) Warning : possible unwanted assignment
> FileUtils.cc line 768 if (filePathStart && (len =
> strlen(filePathStart)))
>
> the old trick of parenthesizing the expr no longer seems to work?

Just my personal opinion here, but wish it had never worked. LOL
Nesting statements like this saves a line or two of code, but makes
code harder to read in the process. I'd just have:

int len = ( filePathStart ? strlen(filePathStart) : 0 );

if ( len )
...

In any case, your code compiles just fine in my application, so I don't
know why you're getting a warning.

> 2) Warning : illegal explicit conversion from 'bool (*)(bool)' to 'void
> *'
[quoted text clipped - 14 lines]
> Gee. These kinds of issues are really not helpful when one has real
> problems to solve..

I don't know why the extern "C" part is in there. I don't see this when
I use UPPs. The following compiles just fine for me:

static pascal
void f( DialogRef theDialog, DialogItemIndex itemNo )
{
}
void RunTest()
{
UserItemUPP u = NewUserItemUPP( f );
}

Out of curiosity, do you really need to stick with the Dialog Manager?

Larry

Reply to this Message

hp - 15 Nov 2005 16:59 GMT

> > Starting my CW9.4 to CW10 migration. So far I am unsuccessful in
> > compiling the simplest of projects. Sigh.

<snip>

> Just my personal opinion here, but wish it had never worked. LOL
> Nesting statements like this saves a line or two of code, but makes
> code harder to read in the process. I'd just have:

understand. Things like this happen when I get lazy. The relational
expr initially only used strlen(), then a later modification to the
block required the value, so to avoid another call to strlen() the
assignment gets created.

> In any case, your code compiles just fine in my application, so I don't
> know why you're getting a warning.

Perhaps there is a pragma for this? I hate to do that, cuz the warning
has saved me before; How about this Ron? Howard?

> > 2) Warning : illegal explicit conversion from 'bool (*)(bool)' to 'void
> > *'

<snip>

This is another warning that is "in the way". I like "clean" builds ...
that way one can be confident the the whole build process is not
introducing new issues...

> > 3) errors about func signatures; eg, when calling NewUserItemUPP(), I
> > get errors about the func ptr:
[quoted text clipped - 10 lines]
> I don't know why the extern "C" part is in there. I don't see this when
> I use UPPs. The following compiles just fine for me:

Again ... can anyone at Metrowerks/FreeWerks comment on this?

This is preventing me from getting anything running; Maybe regressiing
to CW9.5 is the right answer...

> Out of curiosity, do you really need to stick with the Dialog Manager?

Nope. There are just bigger fish to fry...

When a day is 48hrs long, there might be hope of getting caught up.

-harry

Reply to this Message

Mac Forum / Programming / CodeWarrior / November 2005

CW10 assignment, void*, func ptr warnings...