Am 12.04.2016 11:17 schrieb "Sven Barth" <pascaldra...@googlemail.com>: > > Am 12.04.2016 08:57 schrieb "Maciej Izak" <hnb.c...@gmail.com>: > > > > 2016-04-11 23:36 GMT+02:00 Sven Barth <pascaldra...@googlemail.com>: > >> > >> I know this is a rather constructed example, but it's similar to the C++ > >> code we had at work, so it's code that can happen in the real world. > >> If we don't find a way to solve this problem then I'm afraid that I > >> won't include your changes in trunk, cause I don't want to open that can > >> of worms. > > > > > > Eeeee? I am a little shocked by your arguments because that kind of bug is possible since we have initialization/finalization section and uses section in interface/implementation section. *The programmer must be aware of*. The mentioned bugs are here a looong time. For example fixed by me for Lazarus: http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&sortby=date&revision=49547 > > > > That might be, but this just adds a new category of possibilities for such bugs and that is something that we should not do, especially one as subtle as this. > > One possible solution would be to disallow records with management operators for global variables (variables created for Default() might be an exception here, but I'd need to think that through).
Another possibility I just thought of: have the compiler analyse such inter unit dependencies in the initialization sections (yes, I know, easier said than done) and print a warning in case something might depend on the order of execution. If the user is at least aware that there might be something fishy going on then I'm more lenient. Regards, Sven
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel