regis rampnoux wrote:


> And another trouble, when I launch The Gimp:
> gimp: Failed to load one of the brushes in the brush pipe
> "/usr/local/share/gimp/1.2/brushes/SketchBrush-16.gih"


> What is happening?

This has been observed with Silicon Graphics
systems; add yours to the list (what is your
platform, by the way?)

In a few places in brush code, we seek backwards
when we fail to find fingerprints of optional data
chunks.  In doing so, however, we were naive about
Very Large Files and the file systems that support
them (yours, I gather, is among that number).

For example, SGI has an XFS file system, supports
multi-gig files, so that platform can employ 64
bits signed integers for file pointing, (off_t -->
long long --> signed 64 bit integer).

When we decided to seek backwards in a brush file,
we were simply accepting the return value of
"-sizeof(BlahFooeyChunk)". The return value of
"sizeof" is size_t, an unsigned integer (32 bits),
and while applying a unary negation operator to an
unsigned quantity certainly flips the bits, the
compiler (properly) retains the "unsigned integer"
type. So, when the compiler encountered this
value as the off_t (signed 64 bit) bytes-to-seek
in the lseek() parameter list, it performed the
default conversion: the unsigned 32 bit integer
(with merely flipped bits) mapped to a 64 bit
positive signed integer. So we
were seeking very far in the wrong
direction. Sorry about that. Casting sizeof()
expressiions explicitly to off_t seems to
clear up the problem.

I believe this is being fixed and will be
incorporated in  the next stable Gimp (1.2.1)
Real Soon Now.

Be good, be well


P.S. I'm starting the new century with a new ISP;
so my email address is changing:

gosgood "at" --> grosgood "at"


Reply via email to