Web lists-archives.com

Re: [Mingw-users] Using mingw's libpng?




> Date: Tue, 05 Jul 2016 16:54:07 -0700
> From: mathog <mathog@xxxxxxxxxxx>
> Cc: mingw-users@xxxxxxxxxxxxxxxxxxxxx
> 
> On 05-Jul-2016 09:55, Eli Zaretskii wrote:
> Using fprintf() statements and multiple rebuilds of libPNG placed into 
> /usr/local, the location of the failure was tracked to
> 
>     check = fwrite(data, 1, length, (png_FILE_p)(png_ptr->io_ptr));
> 
> in png_default_write_data() in pngwio.c.  The call does not set the 
> check value, it blows up, as does a call to fprintf() or putc() when 
> given the same pointer as a FILE * in the final parameter.  That final 
> parameter is a pointer with the same value as that seen when the file 
> was opened many levels above with:
> 
> fp = fopen(file_name, "wb");
> 
> fprintf(flog," DEBUG MyPng fopened using %s with fp 
> %p\n",file_name,fp);	 fflush(flog);
> 
> fprintf(fp,"DEBUG from MyPNG.c\n"); fflush(fp);
> 
> fprintf(flog," DEBUG wrote DEBUG line to file with fprintf\n");	 
> fflush(flog);
> 
> That all worked correctly and put the expected string into the binary 
> file.
> 
> However, as stated above, none of fwrite, putc, or fprintf will do so 
> with the
> same pointer value (albeit passed as a "png_FILE_p") when invoked within 
> the dll, for instance, like so:
> 
>     FILE *flog = fopen("pngwio2.log","w");
>     FILE *outf = (png_FILE_p)(png_ptr->io_ptr);
>     fprintf(flog,"DEBUG mark 10 writing DEBUG to png file\n"); 
> fflush(flog);
>     int status = fprintf(outf,"DEBUG from pngwio.c\n"); fflush(outf);
>     fprintf(flog," DEBUG wrote DEBUG line to file with fprintf with 
> status %d\n",status);	 fflush(flog);

Are you saying that a FILE * pointer is being created in a DLL, and
then being used outside of that DLL?  That is a no-no on MS-Windows
(and also on other platforms), so that could definitely be part of the
problem.

> In this series the first 3 execute correctly, the 4th explodes, and the 
> 5th is not reached.  Notice that IO works as expected when the fopen and 
> fprintf are in the same function, probably that is also true if they are 
> in the same library.
> 
> There seems to be some sort of mysterious fatal mismatch between file 
> pointers
> opened outside of the DLL, with standard C IO functions invoked on that 
> pointer within the DLL.

It isn't mysterious at all, it's one of those things one should never
do when working with dynamic libraries.  The problem is that the DLL
records the dependency libraries it was linked against, and will only
dynamically link to those same libraries at run time, which might be
different from the libraries used by the main program.  If the stdio
functions used by Python, libpng, and the main functions are not the
same, you cannot use file descriptors and pointers created by one in
code that runs in the other one.

> I think what I really need here is a variant of "png_init_io()" that 
> takes a filename instead of a FILE *.  There doesn't seem to be one now. 

Yes, something like that.  The important thing is: the file pointers
should be used in the same library/program as the one that creates
them.  They cannot be passed across DLLs.

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe