jacklicn / leptonica

Automatically exported from code.google.com/p/leptonica
0 stars 0 forks source link

Many fopen() calls with mode argument "r"/"w" should probably be "rb"/"wb" for Windows builds #12

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a Debug build of leptonica 1.63
2. Create a Debug build of ioformats_reg.exe

What is the expected output? What do you see instead?
I expect ioformats_reg to run without any failures reported.
Instead multiples failures occur.

What version of the product are you using? On what operating system?
leptonlib-1.63.
Microsoft Visual Studio 2008 SP1 with latest updates also applied.
Windows XP Pro SP3.

Please provide any additional information below.
First of all you have to make sure a \tmp directory exists on the drive
from which you are running ioformats_reg. Various parts of leptonica assume
they can write to /tmp and will fail mysteriously if that directory is not
present. (I added a note to that effect in the README I am in the process
of writing).

I was trying out version 7 of libjpeg and happened to stumble across this
error:

jpegio.c

line 227 add:

    cinfo.scale_num = 1;

otherwise cinfo.scale_num seems to default to 8 with the latest libjpeg
version 7.

Finally I suggest you check the mode argument of all calls to fopen(). Most
of them should specify binary mode explicitly by appending a "b".

Here's partial list of the changes that need to be done. This is certainly
incomplete since I was mainly looking for fopen calls related to image
files (I also haven't looked at the prog directory yet other than
ioformats_reg.c):

ioformats_reg.c

line 375

    fp = fopen(filename, "r");

should be changed to:

    fp = fopen(filename, "rb");

-----------

tiffio.c

line 894

    if ((fp = fopen(filename, "r")) == NULL)

should be changed to:

    if ((fp = fopen(filename, "rb")) == NULL)

line 993

        if ((fp = fopen(fname, "r")) == NULL)

should be changed to:

        if ((fp = fopen(fname, "rb")) == NULL)

line 1506:

    if ((fpin = fopen(filein, "r")) == NULL)

should be changed to:

    if ((fpin = fopen(filein, "rb")) == NULL)

----

ccbord.c

should line 2287

    if ((fp = fopen(filename, "r")) == NULL)

really be:

    if ((fp = fopen(filename, "rb")) == NULL)

given that line 2140 is:

    if ((fp = fopen(filename, "wb+")) == NULL)

-----

jbclass.c

should line 1837

    if ((fp = fopen(buf, "w")) == NULL)

really be

    if ((fp = fopen(buf, "wb")) == NULL)

?

----

jpegio.c

line 635

    if ((fp = fopen(filein, "r")) == NULL)

should be changed to:

    if ((fpin = fopen(filein, "rb")) == NULL)

----

psio1,c

line 939

     if ((fp = fopen(filein, "r")) == NULL)

should be changed to:

    if ((fpin = fopen(filein, "rb")) == NULL)

----

psio2.c

line 1465

    if ((fp = fopen(filein, "r")) == NULL)

should be changed to:

    if ((fp = fopen(filein, "rb")) == NULL)

----

utils.c

line 1236

    if ((fp = fopen(fname, "r")) == NULL)

should be changed to:

    if ((fp = fopen(fname, "rb")) == NULL)

line 1297

    fp = fopen(filename, "r");

should be changed to:

    fp = fopen(filename, "rb");

I presume since the function is called nbytesInFile(), you don't want crlf
translation to occur.

not sure but line 1360

     if ((fp = fopen(filename, operation)) == NULL)

should probably be changed to something like:

    strcpy(actualOperation, operation);
    strcat(actualOperation, "b");
    if ((fp = fopen(filename, actualOperation)) == NULL)

where

    char actualOperation[20] = "";

is defined at the top of the function.

Original issue reported on code.google.com by tomp2...@gmail.com on 23 Nov 2009 at 6:15

GoogleCodeExporter commented 9 years ago
Thanks.  I agree that the 'b' flag needs to be added so that these routines 
work 
properly in windows.  These will be fixed in 1.64.

I also appreciate the initialization problem with tiff v. 7, where the scaling 
factor 
numerator must be set to 1.  We won't wait for them to fix the default in v. 
8...

Original comment by dan.bloo...@gmail.com on 24 Nov 2009 at 8:26

GoogleCodeExporter commented 9 years ago
Fixed in 1-64.

Original comment by dan.bloo...@gmail.com on 3 Jan 2010 at 11:25