Package Details: xnp2 0.86-2

Git Clone URL: (read-only, click to copy)
Package Base: xnp2
Description: X Neko Project II, a PC-9801 emulator
Upstream URL:
Licenses: BSD
Submitter: linkmauve
Maintainer: sl1pkn07
Last Packager: sl1pkn07
Votes: 11
Popularity: 0.72
First Submitted: 2012-08-18 09:11
Last Updated: 2018-06-30 02:32

Latest Comments

« First ‹ Previous 1 2 3

Score_Under commented on 2014-11-04 16:35

It's not a gcc bug. These structures aren't packed so they're subject to the usual alignment rules.

If you exclude the very last member of the structs,

sizeof(XF86VidModeModeLine without last member) = 8*sizeof(short) + 2*sizeof(int) = 24

sizeof(XF86VidModeModeInfo without last member) = 8*sizeof(short) + 3*sizeof(int) = 28

On 64 bit machines the last member is 8 bytes long and needs 8 byte alignment. 24 is a multiple of 8 so it needs no padding, but 28 is not so it gets 4 bytes of padding inserted - meaning that in one of these structs there is an invisible 4 bytes that prevents them from being similar to each other. The type punning used here is exactly the kind that leads to undefined behaviour.

Also see

linkmauve commented on 2014-11-04 16:14

It’s apparently the -fstack-protector-strong default parameter for gcc, set by makepkg, that is creating this crash. I don’t see any obvious issue with the current code, aside from potential alignment issue in gcc. To me this looks much more like a gcc bug than a bug in this code.

Score_Under commented on 2014-11-04 15:40

Explanation: The developer has assumed that XF86VidModeModeInfo can be turned into an XF86VidModeModeLine through pointer arithmetic, not realizing that the alignment differences prevent this on x86_64

Score_Under commented on 2014-11-04 15:34

Doesn't work on 64 bit. Patch:

sl1pkn07 commented on 2014-07-13 23:06

new version