Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] constant 0xFFFFFFFFFF overflows int in jbig2 #144

Closed
NagoDede opened this issue Aug 16, 2019 · 6 comments
Closed

[BUG] constant 0xFFFFFFFFFF overflows int in jbig2 #144

NagoDede opened this issue Aug 16, 2019 · 6 comments
Milestone

Comments

@NagoDede
Copy link

NagoDede commented Aug 16, 2019

Description

During ARM (for Raspberry Pi) compilation there is message about int overflow. Cannot build the code on 32bit architecture.

This is related to the use of constant 0xFFFFFFFF... in the jbig2 code and the management of the constants by golang.

Expected Behavior

Code should be robust / portable to 32bits application.
If some part of the code is not 32bits compliant, the functions have to be deactivated or modified for 32bits.

Note 1: In several places, I replace the 0xFFF... constant by math.MaxInt32. Project is building but I didn't run the Unipdf tests. The use of -1 constant value seems more appropriate as it will be independent of the 32bits / 64 bits architecture.

Note 2:
In \github.com\unidoc\unipdf\v3\internal\jbig2\segments\page-information.go, the definition of type PageInformationSegment provides:
// Page bitmap height, four byte, 7.4.8.1
PageBMHeight int
// Page bitmap width, four byte, 7.4.8.1
PageBMWidth int
// Page X resolution, four byte 7.4.8.3
ResolutionX int
// Page Y resolution, four byte 7.4.8.4
ResolutionY int
-->As the 4 bytes shall be respected, it seems more appropriate to use a int32 (or uint32 as height, width,... remain positive?) instead of a int (except if it is explicitly required by the jpeg specification)

Actual Behavior

I build cross compilation on Win 10 for my personal project with the following parameters:
GOARCH=arm
GOOS=linux
GOARM=5

Attachments

Messages issued during compilation:
\github.com\unidoc\unipdf\v3\internal\jbig2\decoder\arithmetic\arithmetic.go:234:2: constant 9223372036854775807 overflows int
..\github.com\unidoc\unipdf\v3\internal\jbig2\segments\halftone-segment.go:341:27: constant 4294967295 overflows int
..\github.com\unidoc\unipdf\v3\internal\jbig2\segments\halftone-segment.go:347:28: constant 4294967295 overflows int
..\github.com\unidoc\unipdf\v3\internal\jbig2\segments\page-information.go:89:20: constant 1099511627775 overflows int
..\github.com\unidoc\unipdf\v3\internal\jbig2\page.go:306:22: constant 4294967295 overflows int

@gunnsth
Copy link
Contributor

gunnsth commented Aug 22, 2019

@NagoDede Does PR #148 resolve this ?

@NagoDede
Copy link
Author

I think PR148 should solve. But how can I test it ? it seems that the update is not in the development branch. So I don't know how/where to get it.

@gunnsth
Copy link
Contributor

gunnsth commented Aug 23, 2019

@NagoDede As can be seen at the bottom of the PR #148 the command line instructions for testing are:

git checkout -b kucjac-iss144 development
git pull https://github.com/kucjac/unipdf.git iss144

@NagoDede
Copy link
Author

PR148 solves the problem. I am to build on default Windows configuration, do the cross compilation.
and launching it on the Raspberry.
Observations: There is a slight difference between the files size, new version generates files 1kb to 2kb more heavy (not a problem)

@gunnsth gunnsth added this to the v3.2.0 milestone Aug 25, 2019
@NagoDede
Copy link
Author

Just to complete my comments: i didn't do specific test on the images by themselves. I can't confirm that the global behavior remains unchanged
My development concern the merging of several pdf files. As a consequence, the beahavior of unipdf for the image/jpeg management was not tested.

gunnsth pushed a commit that referenced this issue Aug 29, 2019
* Fixing platform indepenedent integer size
* Cleared test logs.
* Cleared unnecessary int32
* Defined precise integer size for jbig2 segments.
@gunnsth
Copy link
Contributor

gunnsth commented Aug 29, 2019

Fixed by #148

@gunnsth gunnsth closed this as completed Aug 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants