Hi Damir, Fix size arrays are already protected by definition by the compiler or by CINT. I assume you mean variable length arrays created dynamically. You should use as much as possible classes supporting array semantics for which you will benefit of the built-in protection when using the [] operator. I know that Masa is systematically adding more and more protections in CINT (typical problems in C++ with destructors, scoping problems, objects being delete twice). If you or other users experience protection problems (seg violation), it would be nice to collect reproducable cases in tiny macros that Masa could exploit to improve the robustness of teh system. Rene Brun Damir Buskulic wrote: > > Hi Rene, > > Obviously, this is not a perfect protection. It would simply protect > against overflow/underflow of arrays and corruption of memory in that > case. When one derefrences a zero pointer, it is already protected in > CINT for the interpreted part. In compiled code, there is not much one > can do, I suppose. > This idea came from the fact I'm trying to use a small utility called > Electric Fence, that does memory access checking at run time. The way it > does it is quite clever. It's a kind of insure++ for the poor... though > it's far from checking everything. > > Cheers > > Damir > > Rene Brun wrote: > > > > Hi Damir, > > I am afraid that your suggestion will not help much. > > Most of the time, a seg violation appears when you use a null pointer > > in your code. Could you send us a few examples of seg violation > > that we can reproduce and for which having the scheme that you propose > > would help ? > > > > Rene Brun > > > > Damir Buskulic wrote: > > > > > > Hi, > > > > > > I just had a thought about how to remove/prevent some of the seg > > > violations in ROOT/CINT. This is maybe not at all possible but... > > > I noticed that there are overloaded new and delete operators in ROOT. Is > > > it a weird idea to have these functions maintaining a list of allocated > > > memory, and CINT, when accessing a memory in interpreted mode, looking > > > at this list to determine if the operation is legal or not. > > > This would lead obviously to a slowdown of the whole operation of the > > > interpreter but it could be a special "protected" mode. > > > > > > what are the showstoppers ? Am i missing something obvious ? > > > > > > Damir > > > -- > > > ===================================================================== > > > | Damir Buskulic | Universite de Savoie/LAPP | > > > | | Chemin de Bellevue, B.P. 110 | > > > | Tel : +33 (0)450091600 | F-74941 Annecy-le-Vieux Cedex | > > > | e-mail: buskulic@lapp.in2p3.fr | FRANCE | > > > ===================================================================== > > > mailto:buskulic@lapp.in2p3.fr > > -- > ===================================================================== > | Damir Buskulic | Universite de Savoie/LAPP | > | | Chemin de Bellevue, B.P. 110 | > | Tel : +33 (0)450091600 | F-74941 Annecy-le-Vieux Cedex | > | e-mail: buskulic@lapp.in2p3.fr | FRANCE | > ===================================================================== > mailto:buskulic@lapp.in2p3.fr
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:20 MET