Re: [Plib-devel] Porting plib to compile under win32/borland; bugs/leaks report

[Maciej K. <Mac...@cs...>]

> > In general, all fopen("ra") are not valid under borland. "a" is
> > equivalent to "t" (=text). Thus every open("ra") should be changed
> > to "rt".
> 
> Are you *sure* about that?
> 
> That "ra" mechanism is pretty firmly embedded in Windoze C/C++ compilers
> and I find it VERY hard to believe that Borland would go against that
> convention.  I used Borland C++ back in the days of DOS and it certainly
> allowed "ra" back then.

Borland 5 (released 2000) writes:

To specify that a given file is being opened or created in text mode
append a t to the mode string (rt w+t and so on). Similarly to specify
binary mode append a b to the mode string (wb a+b and so on). fopen also
allows the t or b to be inserted between the letter and the + character
in the mode string; for example rt+ is equivalent to r+t. 
"a" stands for "append" (open for writing at the end of file).

Borland 3.1 (released 1990) says the same.


> > This could be resolved by using a global macro, like
> >
> > #ifdef __BORLANDC__
> >  #define FOPEN_READ "rt"
> >  #define FOPEN_WRITE "wt"
> > #else
> >  #define FOPEN_READ "ra"
> >  #define FOPEN_WRITE "wa"
> > #endif
> >
> > ...=fopen(f,FOPEN_READ);
> 
> Bleaugh!

We have to do it in our portable source.


> > Functions
> >
> > ssgLoaderOptions* ssgGetCurrentOptions ()
> > void ssgSetCurrentOptions ( ssgLoaderOptions* options )
> > ssgEntity *ssgLoad ( char *fname, ssgBranch *(*cb)(char *))
> > void ssgSetAppStateCallback ( ssgState *(*cb)(char *) )
> > void ssgModelPath   ( const char *path )
> > void ssgTexturePath ( const char *path )
> >
> > could be moved to ssg.cxx. It would make it easier to produce libs/dlls
> > from the source.
> 
> Why?   I don't understand that.

Generally, in some cases the .h file
and their definition will be compiled twice with different 
attributes, and then linked to the same executable. The link 
will fail then. (executable = some program using plib).

That is because the same .h file is compiled during plib
compile, and also during executable compile. During plib
compile (i.e. in 'make library' mode) functions may require some
special attributes (like "exportable"), which is not the case
during executable compile.

> > Directories are under Win32 separated by \, not /.
> 
> But modern C/C++ compilers and libraries take care of that don't they?
> The CygWin and MSVC guys don't have a problem with this.

Borland treats / as a standard name char, not as \.
I wonder if MSVC cares for this; enter a name with / under windows
and it won't treat it as \.


> > In many places, new[] is NOT matched by delete[] but by delete.
> > I will not include the long list here, but it would be nice to
> > fix all occurences.
> 
> Yes - unfortunately, Linux, IRIX and Solaris allow that - which makes
> it hard for me to find the problem.

It is also O.K. to Borland, but some source-profiling tools detect
it. Anyway that's how it should be done.

> Could you list those places so we can fix them.
> > There are numerous memory leaks, especially in loaders. Hopefully
> > they will be located.
> Could you be more specific?

I will try to send a report some time in the future.



MacKo