regis rampnoux wrote: <snipped...> > 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" <snipped...> > > 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 Garry -------------- P.S. I'm starting the new century with a new ISP; so my email address is changing: gosgood "at" idt.net --> grosgood "at" rcn.com BGBW -GRO
