nanogui: Fonts offset leads to wrong memory location -- genfont.c bug??
Subject:
Fonts offset leads to wrong memory location -- genfont.c bug??
From:
"Ricardo P. Jasinski" ####@####.####
Date:
17 Nov 2006 12:52:56 +0000
Message-Id: <20061116200754.3D8498612@thialf.cpdtt.cefetpr.br>
Hello everyone,
I'm running microwindows-0.91 in an Altera Nios II processor (which happens
to be a soft-core 32-bit processor implemented inside an FPGA). I was able
to compile and run it in my prototype system which has a PS2 mouse and a VGA
monitor.
When I tried to replace one of the built-in fonts, weird things started to
show up on the screen. Obviously, one of the routines was reading the font
bitmaps from the wrong memory location.
I realized that the C language files created with the convfnt32.exe tool
generated a font structure like:
MWCFONT font_winArial8x22 = {
"winArial8x22", 19, 22, 18, 30, 226,
winArial8x22_bits,
winArial8x22_offset,
winArial8x22_width,
};
while the files distributed with microwindows had a structure like:
MWCFONT font_winFreeSansSerif11x13 = {
"winFreeSansSerif11x13", 11, 13, 11, 32, 224,
winFreeSansSerif11x13_bits,
0 /*winFreeSansSerif11x13_offset*/, // <-- note this zero
here!
winFreeSansSerif11x13_width,
};
My first attempt was replacing 'winArial8x22_offset' with the value 0. It
indeed solved the problem, but it only worked for monospaced (fixed width)
fonts.
Single-stepping through the code, I located the source of the problem (line
171 in genfont.c):
/* get font bitmap depending on fixed pitch or not*/
bits = pf->bits + (pf->offset? pf->offset[ch]: (pf->height * ch));
So, when offset is 0, the actual offset value is not uset to calculate the
bitmap address in memory, and everything works fine. However, any non-zero
value would cause the calculation to lead to the wrong memory location.
I was able to get things working by making the following change:
//bits = pf->bits + (pf->offset? pf->offset[ch]: (pf->height * ch));
bits = pf->bits + (pf->offset? ((unsigned short *)pf->offset)[ch] :
(pf->height * ch));
Now, I believe that the root of all problems was that the 'offset' variable
was declared as an 'unsigned long *', while 'bits' was an 'unsigned short
*'. Actually, 'bits' is declared as a pointer to the MWIMAGEBITS type,
which in turn is defined as an unsigned short. I'm not sure it is a good
thing to have these two types mixed when doing pointer arithmetic.
My question is: does this qualify as a bug? Shouldn't it be fixed in
upcoming versions? I'm just getting started with microwindows, so I don't
feel confident enough for making changes in its core code, but this really
seems the right thing to do.
I would appreciate any comments on this matter. Cheers!!
Ricardo Jasinski.
