Illegal implicit casts break CodeWarrior6



Build Config
17 years ago
14 years ago


(Reporter: Andrew Thompson, Assigned: Andrew Thompson)


Mac OS X

Firefox Tracking Flags

(Not tracked)



(6 attachments)



17 years ago
CodeWarrior 6 can't build libreg.mcp due to an illegal implicit cast from (char *
*) to (void **). Why do I feel that I'm gonna find a few of these?

Patch will be attached shortly

Comment 1

17 years ago
Created attachment 30900 [details] [diff] [review]
Make cast explicit


17 years ago
Blocks: 53682

Comment 2

17 years ago
Created attachment 30901 [details] [diff] [review]
Same problem in libpref. (hmm, .c and .cp files being compiled as C++?)

Comment 3

17 years ago
Generalised bug, not specific to libreg.

Interesting;y, CW6 seems to be applyng C++ rules to reg.c
Summary: Illegal implicit cast in libreg breaks CodeWarrior6 → Illegal implicit casts break CodeWarrior6

Comment 4

17 years ago
Created attachment 30931 [details] [diff] [review]
Patch to fix errors building GFX

Comment 5

17 years ago
Created attachment 30933 [details] [diff] [review]
Patch to fix casts in plugins

Comment 6

17 years ago
Created attachment 30942 [details] [diff] [review]
Fix void ** cast in widget.mcp

Comment 7

17 years ago
Created attachment 30947 [details] [diff] [review]
Fixes to InternetConfig and Mime services

Comment 8

17 years ago
Are we sure there aren't some compiler options that might be a better way to fix
this? How about the "relaxed pointer type rules" option?


17 years ago
Priority: -- → P3
Target Milestone: --- → mozilla1.0

Comment 9

17 years ago
Um, well, 

* There are only 6 fixes to make in the whole tree.

* Why would we want to disable errors being generated from code which is illegal
according to the C++ spec (or so I'm told).

Obviously one of these errors at least is for a C file and is legal, but having
the casts made explicit actually serves to document what's happening in the code
more clearly, IMO.

Comment 10

17 years ago
BTW, the changes I made were purely to make it compile. If anyone can look at
them and say they're conceptually wrong and a better fix it needed, please pipe
up now!

Comment 11

17 years ago
This one looks suspicious to me:

-       aContext.GetDeviceContext(*getter_AddRefs(theDevContext));
+       aContext.GetDeviceContext((nsIDeviceContext *&)*

and there's a double cast here which looks wrong:

-  (nsIWidget*)(aEvent->widget)->GetClientData((PluginViewerImpl *)pluginViewer);
+  (nsIWidget*)(aEvent->widget)->GetClientData((void *&)(PluginViewerImpl *

The rest looks good.

Comment 12

17 years ago
This should not be mine. Reassigning to since he's been doing
all the work
Assignee: jj → lordpixel

Comment 13

17 years ago
If this doesn't break CW7 let's close this as WONTIX


Comment 14

17 years ago
Well, I don't have 7 to check. Its possible that many of these have been fixed 
along the way in other bugs. Last time I asked somone said all of the CW7 builds 
are on a branch and no fixes have been checked into the trunk. Is this still 
true? If so, we won't know if all of them have been fixed. I don't know if its 
possible to build the trunk in CW 7?

Comment 15

17 years ago
ccarlen got a branch building on Pro7 and our target to land that on the trunk
is the end of October (2001 for you pessimists :-)  I'm gonna close this and
75333 as WONTFIX.  Sorry to throw away the work Andy but since we skipped Pro6
(and it may very well be that ccarlen used some of this for Pro7 so we're prlooy
not actually throwing it away...
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 16

17 years ago
verified wontfix.

Comment 17

17 years ago
no, really.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.