On Sun, 22 Jan 2006 22:51:44 +1000 David Seikel <[EMAIL PROTECTED]> wrote:
> The possible problem is the allocate on the stack then return. Since > the config dialog hangs around the structure allocated on the stack is > used long after the function that allocated it returns. I know it has > been a long time since I first started coding in C, but I don't think > they have changed stacks that much. Surely the structure on the stack > is in danger of getting overwritten at some later function call? It's > a wonder that config dialogs worked at all. It might explain the > crashes some people have reported though. OK, so I didn't spot that * before. The reason it's not crashing is coz it's copying the contents of the view struct, and not the pointer. > The actual fix I leave as a matter for discussion. Prompted by CodeWarrior, who suggested that since devilhorns and myself where the main ones concerned with this bit of code, we discussed it and decided on a fix. By now our fixes are in cvs. The E_Config_Dialog_View struct must now be calloc'ed by the calling code, e_config_dialog will free it when it is finished with it. The close_cfdata callback can be added to the structure at the same time as the rest of the callbacks, since it can now be assumed to be NULL if not explicitly set. This change does mean that any users of config_dialog that is outside of the sf.net cvs, and thus outside of our control, must be modified, or a crash will happen when config_dialog tries to free() the stack allocated ram.
pgpX24IE9qG2V.pgp
Description: PGP signature
