[cgma-dev] cgm-cubit on 32 bit machine

[Iulian Grindeanu]

> >
> > Maybe tmpnam use is what causes the problem (some say that tmpnam
> > should
> > never be used on linux) I tried something else (like a hard-coded
> > tmp
> > file name) and it did not fix it. So I think we can rule out tmpnam.
> >
> 
> This definitely has nothing to do with tmpnam. And the issue with
> tmpnam is
> a) a conceptual problem with the lack of atomicity resulting from the
> selection of the name and the creation of the file being separate
> steps, not
> just linux problem and b) it is certainly still present in whatever
> replacement implementation you tried.

Thanks Jason, for extensive description. I was almost sure it is not tmpnam at fault, but your explanation re-enforced this belief.
> 
> 
> > Anyway, if I just declare a "buffer" after the file definition, like
> > in
> > NCubitFile::CCubitFile ccf; int buff[10]= {0};buff[1] =0;
> >
> > the memory does not get corrupted, and testgeom tridata1.cub
> > finishes
> > fine.
> >
> > So I am wondering if it is something wrong in CCubitFile
> > object/constructor that corrupts the memory.
> >
> 
> Try setting a watch point in the debugger for one of the bytes that
> gets
> corrupted. Then you'll know where the corruption is happening.
> 
So the corruption in that string happens exactly when I step over the NCubitFile::CCubitFile ccf; statement. 

That class/object has something, because I cannot step into any of its methods (or constructor), the debugger skips over it; I will try rebuilding with -O0 flag (it is configured with enable-debug and disable-optimize, but I do not see -O0 anywhere in makefiles)

Does anyone else, besides Rajeev and I, builds cgm on 32 bit machine?

Thanks,
Iulian