Click here to go to the forum index Click here for the home page
 
Author Message

<  TAP and patch development  ~  Compiler bug?

Page 1 of 1
R2-D2
Posted: Tue May 18, 2010 1:24 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
Anyone come across a problem with calling a TAP API function being rejected by the compiler? The error I'm getting with a straight call is "called object is not a function". This is the code:
Code:
TAP_MemFree(buf);
Can't really get much simpler than that. It's particular to this call, in this location in the code. There's no funny business in my code about changing what TAP_MemFree means -- if there were, I'd expect there'd also be something analogous happening with TAP_MemAlloc, but changing the code to a TAP_MemAlloc call works fine.

So I changed that code to this block:
Code:
{
  int (*f)(const void *) = TAP_MemFree;
  f(buf);
}
This complained about the same issue, showing that it doesn't understand what TAP_MemFree is any more -- the specific error was now "warning: initialization makes pointer from integer without a cast". If I move this initialised declaration back a couple of levels out then everything works fine -- but the intervening code doesn't redeclare TAP_MemFree or do anything odd. In fact, I can move it a little less far back (and still get the error) but everything works fine if I eliminate a couple of intervening blocks of code.

Confused Known compiler bug?

_________________
Troubleshooting -- User Manual -- Dark Side of the Matrix: Firmwares and Patches
View user's profile Send private message Visit poster's website
R2-D2
Posted: Tue May 18, 2010 6:55 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
I've now got it so that I get the above error if I try to compile the code with this section in:
Code:
int (*f)(const void *) = TAP_MemFree;
dword heap, free, avail=0;
But no error if I swap those lines. Confused I think I'm convinced now that it's a compiler bug.

_________________
Troubleshooting -- User Manual -- Dark Side of the Matrix: Firmwares and Patches
View user's profile Send private message Visit poster's website
adi
Posted: Tue May 18, 2010 8:49 pm Reply with quote
Frequent contributor Joined: 24 May 2006 Posts: 124
Can't really help on this but was wondering what it does if you redeclare the prototype for the function? Does look like a compiler problem to me though.

_________________
TF5800, TS On, F/W: MS6 Recommended F/W 12/9/2009 +C0DEvEzFsHsIMPePfPsScTaUUuUxVdZ
TAPs: QuickJump 1.72; MyStuff 6.6; EIT Sub (Game) v0.6; EPG2MEI v0.96; Font Manager 1.0; MyInfo B5.6; SecCache (UK) v0.4; TAP Commander 1.34; TSSaver v0.5; UK Subtitle 1.9; TF5000 Display v1.53; PruneEPG 1.0; (FastScanGUI v0.6d);
Sig generated by MyInfo on 5/11/15
?
View user's profile Send private message
mstombs
Posted: Tue May 18, 2010 8:51 pm Reply with quote
Frequent contributor Joined: 31 Dec 2006 Posts: 938
I'm completely out of my depth here, but does it not like the call with buf because it is expecting a type "const void* addr" as per your documentation here

http://www.toppy.org.uk/~r2-d2/api/TAPMemFree.html

_________________
TF5800 1.5TB, TS On, NSLU2 + unslung 6.10 + WD500GB + MWI 0.66, F/W: MS6 Recommended F/W 12/9/2009 -Fm+AfBmC0CfCtFsIMPePfPsScUWfWs
TAPs: EPG2MEI v0.96; QuickJump 1.72; SecCache (UK) v0.4; (MyInfo B5.6); MHEG On/Off A3; Extend v1.7; MyStuff 6.6; DumbWidescreenTV 2.44; TF5000 Display v1.53; PruneEPG 1.0; (EIT Sub v0.6 SnG);
Sig generated with help from MyInfo on 18/4/15
?
View user's profile Send private message TF5800
R2-D2
Posted: Tue May 18, 2010 9:28 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
All the datatypes and stuff are correct... I've found a neater 'solution' by wrapping an initial section of code in its own block. I think the above example shows that it's got something to do with the number of variables in scope when TAP_MemFree is accessed. The compiler messes up for some reason (on seemingly just that TAP function). Localising a few declarations to their own block seems to free up some variable space for the later code, in the same way that swapping the order of declaration worked. Confused

It's hardly a real solution, but we are stuck with an old (and very hacked) version of GCC, so I imagine there are plenty of other known problems.

_________________
Troubleshooting -- User Manual -- Dark Side of the Matrix: Firmwares and Patches
View user's profile Send private message Visit poster's website

Display posts from previous:  

All times are GMT + 1 Hour
Page 1 of 1

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum