rouaix@inria.UUCP (09/30/87)
I have a question about SetWindowTitles and memory allocation. Suppose you have a window with a title "Shoobeedoo". Let's call SetWindowTitles(window,"Wapdoowap",0). What happens to the string "Shoobeedoo" ??? 1) Now who deallocates the memory used by the string "Shoobeedoo" ?? 2) It's reasonnable to think that the pointer to the window's titles string will be updated. What happens if the string "Wapdoowap" is somewhere in the stack, and then after some other code, this part of the stack is destroyed ? Does SetWindowTitles() copy the string for its own use ?? More generally, do we have such functions that use memory they can't deallocate anyway ? -- *- Francois Rouaix / When the going gets tough, * *- USENET:rouaix@inria.inria.fr \/ the guru goes meditating...* * SYSOP of Sgt. Flam's Lonely Amigas Club. (33) (1) 39-55-84-59 (Videotext) *
dillon@CORY.BERKELEY.EDU.UUCP (10/03/87)
> I have a question about SetWindowTitles and memory allocation. > Suppose you have a window with a title "Shoobeedoo". > Let's call SetWindowTitles(window,"Wapdoowap",0). > What happens to the string "Shoobeedoo" ??? SetWindowTitles() does not duplicate the string. Rather, it uses the string you pass to it. Since no assumptions on the string you pass it can be made, no memory allocation or freeing is done. So if you allocate the string you give to SetWindowTitles() you must deallocate after you close the window (or make a call with a different string to SetWindowTitles()). Otherwise you generally don't have to worry about it. >2) It's reasonnable to think that the pointer to the window's titles > string will be updated. What happens if the string "Wapdoowap" is > somewhere in the stack, and then after some other code, this > part of the stack is destroyed ? > Does SetWindowTitles() copy the string for its own use ?? As SetWindowTitles() does not copy the string, you must be sure to keep that string around while it is being used in SetWindowTitles(). If you modify the string, you want to make a call to SetWindowTitles() to ensure it is updated properly. Note that you should be careful about modifying the string. If Intuition decides to look at it while you're in the middle of modifying it... specifically if you've overwritten the end of string mark (0)! >More generally, do we have such functions that use memory they can't >deallocate anyway ? Any library call that requires a string will either (A) use the string pointer provided or (B) copy it and handle the copy internally. In the case of (A), it will either (1) use the string and then discard it or (2) use the string and expect the string to stay valid after returning. Open() would use the filename then not care what you use that string for after it returns. SetWindowTitles() as we know keeps the pointer around. -Matt
bryce@hoser.berkeley.edu.UUCP (10/03/87)
In article <534@inria.UUCP> rouaix@inria.UUCP (Francois Rouaix) writes: > > Suppose you have a window with a title "Shoobeedoo". > Let's call SetWindowTitles(window,"Wapdoowap",0). > What happens to the string "Shoobeedoo" ??? > >1) Now who deallocates the memory used by the string "Shoobeedoo" ?? Whoever allocated it. When you open a window you pass a static string for the title. When you change titles you just tell Intuition to set it's internal pointer to this _other_ section of memory. You own all the memory involved. You allocate it, you deallocate it. Normally it will just be part of your DATA segment/hunk and you don't need to think about it. [In a more general and esoteric sense... Window structure had better inherit task pointers at some point or the input.device is going to have quite a time convincing the MMU, "No, really. I have a right to look at that memory." Just one of many little rocks on the way to protection.] |\ /| . Ack! (NAK, ENQ, SYN) {o O} . (") bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce U How can you go back if you have not yet gone forth?