Hallo Fred, vous ecrit au Sat, 12 Nov 2022 16:23:22 +0000:
> Hello Sieghard and sorry for the delay. No problem, no need to hurry. > About the added "check", It is because I get crash if, using > mse_dynpo, the application at loading did not correctly load the > array of lang. It can appear if you load twice the application or if Yes, I can imagine that this can happen, when and if you don't use the compatibility functions, but insist to do everything "by hand". The compatibility functions are explicitely there to resolve problems that could arise that way, and that's why they do check for correct initialization internally. Or, rather, that's what they are supposed to do, anyway. Because of an experiment, trying to compile your ideU with all variations of using mse_dynpo, mo files and libfontconfig, I found an omission which might have provoked a failure. It's in the access properties to the "extended" and "langnames" arrays. This made an amendment of the mse_dynpo version of the "msestockobjects" unit neccessary. It's in the new version of the "mseide-msegui-shadow.zip" file that should be accessible on my web site. > the array is corrupted. Also, for example with rpi-aarch64, there was How could (one of) the arrray(s) become corrupted? This should only be possible by uncontrolled memory access, through untyped and manipulated pointers, e.g., or caused by faulty code because of a compiler failure or a faulty library. This isn't C, where everyone constantly has to mess with freely accessible pointers and without any type and other checking. But indeed, I didn't check with arm code (although this might be an option to explore) and as I don't have good access for testing there, on Windows, too BTW, I also included an amendment to the ide code, which uses a chunk of obsolete definitions that caused compiler errors and failures of the msespice application from Martin in its original version. I had to remove some code, and the definition of this data structure that's obviously nowhere used, any more, at least. > a bug (fixed now) and because the array of lang was not yet filled, > when msegui raised a error, that error message crashed the app And that is correct behaviour of the software! The library routines were not used as intended, so data structures could end up not or only partially initialized, what apparently happened. > > they ALL check for the arrays containig data beyond sc_All, ... > I agree with you, it not the best way (but now all works ok). No, the best way should be a method to EXCLUDE use of these data structures and functions in a way that could provoke a failure. That's what the objects in object oriented programming are meant for, I suppose? Vous ecrit au Sat, 12 Nov 2022 16:35:48 +0000: > Sorry to come one more time with the same song. > But it would be *much* easier for me if you use GitHub site for all > commits-code-discussion things. Well may be for you. Not for me though, as I'm not so often on line. On the other hand, my machine takes care of handling email and news without need for manual interaction, and it takes almost no time to handle all of these, so only very little time for aggressors to intermingle and disturb. A local mail server (exim) and news server (something like leafnode) do this job in conjunction with a couple cron jobs to control their external working. I'm very satisfied with the setup, and that's working for literally decades now. Yes, but there's still a little catch, as this is basically a mailing list - which would still be handled by my setup - that I'm reading through a mailing-list-to-news-group converter server, so I "see" it like a news group. But that's just a detail of convenience. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- _______________________________________________ mseide-msegui-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
