Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs have moved to the Altera Community. Existing Intel Community members can sign in with their current credentials.
29309 Discussions

IVF's Bug or Mine? (XFT Porting Woes)

Jugoslav_Dujic
Valued Contributor II
851 Views
I suspect I discovered another couple of bugs on IVF while porting XFT to IVF8. I have the latest release (047+048 patch). The first is related with FUNCTION returning POINTER. Explicit interfaces all around:
FUNCTION XCreateWindow(...xParent...)
TYPE(X_WINDOW):: xParent
...
END FUNCTION XCreateWindow
!=====================
FUNCTION XGetWindow() RESULT(xWnd)
TYPE(X_WINDOW), POINTER:: xWnd
TYPE(X_WINDOW), SAVE, TARGET::   xLocal
...
xWnd=>xLocal
...
END FUNCTION XGetWindow
!=====================
...
i = XCreateWindow(...XGetWindow()...)
I suppose that at the end of story -- provided that the code is legal, xParent and xLocal should be associated. However, that is not the case; instead of LOC(xLocal), what is being passed to XCreateWindow is LOC(LOC(xLocal)) (if you know what I mean), i.e. address of the pointer itself rather than its target.
The workaround is to insert a temporary variable in the calling code:
TYPE(X_WINDOW),POINTER:: xTemp
...
xTemp=>XGetWindow()
i = XCreateWindow(...xTemp...)
Jugoslav
0 Kudos
3 Replies
Jugoslav_Dujic
Valued Contributor II
851 Views
I'm still scratching my head on the second one:
CHARACTER, ALLOCATABLE:: sText(:)
...
iLen = SendMessage(xCtl%hWnd, CB_GETLBTEXTLEN, iSel, 0)
ALLOCATE(sText(iLen+1))
iSt = SendMessage(xCtl%hWnd, CB_GETLBTEXT, iSel, LOC(sText))
iSt = SendMessage(xCtl%hWnd, WM_SETTEXT, 0, LOC(sText))
DEALLOCATE(sText)
On return from CB_GETLBTEXT, LOC(sText) is screwed. DEALLOCATE(sText) fails. If I replace sText to be a non-allocatable array of sufficient size, it works all OK.
I have a hunch thatthis oneis related with the one above. If I watch LOC(sText) in the code above, after return from SendMessage, it changes value to 0x286e6973, which exactly matches first 4 bytes of combo box contents - "sin(". It appears that instead of LOC(sText), address of descriptor is incorrectly passed to SendMessage.
Jugoslav
0 Kudos
Steven_L_Intel1
Employee
851 Views
Jugoslav, perhaps it's because I'm still working on my first coffee of the morning, but I'm having trouble understanding what you're doing here, and am not sure if it's legal. If possible, please create a small, self-contained test case and submit it to Premier Support. Then send me an e-mail with the case number. Thanks.
0 Kudos
Jugoslav_Dujic
Valued Contributor II
851 Views

No problem Steve, I'm working on creating a smaller sample.

Another Saturday worker, ha? :-(

Jugoslav

0 Kudos
Reply