🚀 go-pugleaf

Update:

In 4_9s, if connected over sgifaceserver, a command that outputs a gif
image to standard output:

> gif map mymap;gifdump -

will include the trailing NULL (from the C-string?) after the first line:

// 11052 bytes
^@GIF89a....

Only sgifaceserver will do this. The giface client will not include 
trailing NULLs if printing to standard output. 

AcePerl's obj->asGif method will fail producing a valid gif-file from this
output, as it will not split away the NULL byte in front of GIF89a.

Following change in Ace::Object.pm will fix it. It's not the correct fix
(which should be made in AceDB source, not in AcePerl), however, just a
workaround.

Object.pm line 1764, Aceperl 1.86:
- return unless ($bytes, $trim) = $data=~m!^// (\d+) bytes\n(.+)!sm;
+ return unless ($bytes, $trim) = $data=~m!^// (\d+) bytes\n\x0?(.+)!sm;


But I'm still interested to know if others have seen this problem, or if I 
just screwed something up. I have it on two diffent machines though..

MHu



On Mon, 7 Jul 2003, Morten Hulden wrote:

> 
> After upgrading to ACEDB_4.9s, sgifserver seems to provide gif-images 
> where the first byte is NULL and the last byte is dropped. 
> 
> AcePerl now outputs faulty gifs with the obj->asGif method (Object.pm). As
> AcePerl has not changed, and giface client produces good gifs I assume
> something changed in sgifserver. Anyone else seen this?
> 
> I also tested 4.9u with same results.
> Compiled with gcc 3.2.2 on Linux RH9, -O2/-03 optimation.
> 
> MHu
>