giflib-devel — Mailing list for development of libungif/giflib.

[giflib-devel] Add new function to gif_lib.h - symbol look up error

[Alexander I. <ai...@ya...>]

Hello,

I was trying to add a function to dgif_lib.c. First just a test-function. After compiling and reinstalling the giflib, my function is in gif_lib.h in the /include dir. But i get a symbol look up error for this function when calling it.

What's the correct way to make a function in gif_lib.h?

Thanks
Alex

Re: [giflib-devel] [Opensource-releasing] [PATCH] Const-correctness in giflib.

[Daniel B. <da...@go...>]

lgtm

On Thu, Nov 14, 2013 at 4:39 PM, Adam Buchbinder <abu...@go...> wrote:
> Two functions (GifErrorString and EGifGetGifVersion) are declared as
> returning char*, but really return const char*. The code now builds with
> more warnings enabled. The attached patch corrects the issue.
>
> Adam Buchbinder
> Google, Inc.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Opensource-releasing" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ope...@go....
> To post to this group, send email to ope...@go....
> Visit this group at
> http://groups.google.com/a/google.com/group/opensource-releasing/.
> For more options, visit
> https://groups.google.com/a/google.com/groups/opt_out.

[giflib-devel] [PATCH] Const-correctness in giflib.

[Adam B. <abu...@go...>]

diff -durp giflib-5.0.4/lib/egif_lib.c src/egif_lib.c
--- giflib-5.0.4/lib/egif_lib.c	2013-02-11 13:40:01.000000000 -0800
+++ src/egif_lib.c	2013-11-14 10:48:40.000000000 -0800
@@ -184,7 +184,7 @@ EGifOpen(void *userData, OutputFunc writ
 /******************************************************************************
  Routine to compute the GIF version that will be written on output.
 ******************************************************************************/
-char *
+const char *
 EGifGetGifVersion(GifFileType *GifFile)
 {
     GifFilePrivateType *Private = (GifFilePrivateType *) GifFile->Private;
@@ -265,7 +265,7 @@ EGifPutScreenDesc(GifFileType *GifFile,
 {
     GifByteType Buf[3];
     GifFilePrivateType *Private = (GifFilePrivateType *) GifFile->Private;
-    char *write_version;
+    const char *write_version;
 
     if (Private->FileState & FILE_STATE_SCREEN) {
         /* If already has screen descriptor - something is wrong! */
diff -durp giflib-5.0.4/lib/gif_err.c src/gif_err.c
--- giflib-5.0.4/lib/gif_err.c	2013-02-11 13:40:01.000000000 -0800
+++ src/gif_err.c	2013-11-14 10:48:40.000000000 -0800
@@ -12,10 +12,10 @@ gif_err.c - handle error reporting for t
 /*****************************************************************************
  Return a string description of  the last GIF error
 *****************************************************************************/
-char *
+const char *
 GifErrorString(int ErrorCode)
 {
-    char *Err;
+    const char *Err;
 
     switch (ErrorCode) {
       case E_GIF_ERR_OPEN_FAILED:
diff -durp giflib-5.0.4/lib/gif_lib.h src/gif_lib.h
--- giflib-5.0.4/lib/gif_lib.h	2013-02-11 13:40:01.000000000 -0800
+++ src/gif_lib.h	2013-11-14 10:48:40.000000000 -0800
@@ -127,7 +127,7 @@ GifFileType *EGifOpenFileName(const char
 GifFileType *EGifOpenFileHandle(const int GifFileHandle, int *Error);
 GifFileType *EGifOpen(void *userPtr, OutputFunc writeFunc, int *Error);
 int EGifSpew(GifFileType * GifFile);
-char *EGifGetGifVersion(GifFileType *GifFile); /* new in 5.x */
+const char *EGifGetGifVersion(GifFileType *GifFile); /* new in 5.x */
 int EGifCloseFile(GifFileType * GifFile);
 
 #define E_GIF_ERR_OPEN_FAILED    1    /* And EGif possible errors. */
@@ -222,7 +222,7 @@ int GifQuantizeBuffer(unsigned int Width
 /******************************************************************************
  Error handling and reporting.
 ******************************************************************************/
-extern char *GifErrorString(int ErrorCode);     /* new in 2012 - ESR */
+extern const char *GifErrorString(int ErrorCode);     /* new in 2012 - ESR */
 
 /*****************************************************************************
  Everything below this point is new after version 1.2, supporting `slurp

[giflib-devel] [PATCH] Include stddef.h because size_t is used in GCB API

[Alexander S. <ecl...@gm...>]

Signed-off-by: Alexander Strasser <ecl...@gm...>
---

  This was probably not noticed often yet, because
most of the time standard headers are included before
that pull in the definition of size_t .

 lib/gif_lib.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/gif_lib.h b/lib/gif_lib.h
index 9ba3565..1eb93b8 100644
--- a/lib/gif_lib.h
+++ b/lib/gif_lib.h
@@ -18,6 +18,7 @@ extern "C" {
 #define GIF_ERROR   0
 #define GIF_OK      1
 
+#include <stddef.h>
 #include <stdbool.h>
 
 #define GIF_STAMP "GIFVER"          /* First chars in file - GIF stamp.  */
-- 

Re: [giflib-devel] [PATCH] fix dir delimiter for mingw

[Eric S. R. <es...@th...>]

Mark Brand <ma...@ma...>:
> Oops, I should have made clear that the purpose of the patch is to make 
> cross compiling on unix possible. The regular '/' directory delimiter 
> should work building on either platform.

Merged, thanks.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [giflib-devel] [PATCH] fix dir delimiter for mingw

[Mark B. <ma...@ma...>]

Oops, I should have made clear that the purpose of the patch is to make 
cross compiling on unix possible. The regular '/' directory delimiter 
should work building on either platform.

[giflib-devel] [PATCH] fix dir delimiter for mingw

[Mark B. <ma...@ma...>]

regards,

Mark

Re: [giflib-devel] libgif and libungif usage

[Eric S. R. <es...@th...>]

GAURAV GUPTA <ya1...@gm...>:
> I am a user of libungif 4.1.4. There is no advancement in this project now.
> But I have seen libgif 5.0.0 release recently. I want to confirm if i can
> replace libungif with new libgif 5.0.0 in my application? Is new libgif
> 5.0.0 is compatible with libungif 4.1.4, or some modifications need to be
> done?

Your source code will require minor modifications.  There's a section on
forwards and backward compatibility in the library documentation that 
explains the API changes in detail.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[giflib-devel] libgif and libungif usage

[GAURAV G. <ya1...@gm...>]

Hi,

I am a user of libungif 4.1.4. There is no advancement in this project now.
But I have seen libgif 5.0.0 release recently. I want to confirm if i can
replace libungif with new libgif 5.0.0 in my application? Is new libgif
5.0.0 is compatible with libungif 4.1.4, or some modifications need to be
done?

-- 
Regards,
Gaurav*
*

[giflib-devel] GIFLIB appears ready for 5.0 release

[<es...@th...>]

All tracker bugs have been fixed.  All feature requests have been
resolved.  All patches have been accepted or rejected.  The code is
coppcheck and Coverity clean.

Almost everything on Toshio's 5.x wishlist is done - notably, I've
given the extensions portion of the API the overhaul he rightly said
was needed.  There's one significant new feature - support for reading
and editing graphics extension blocks through a convenient structure.

Changes to the API require a library major-version bump. Application
code using the DGifSlurp()/EGifSpew() interface to extension blocks
will require minor changes.

Code Fixes
----------
* Fixes applied for CVE-2005-2974 and CVE-2005-3350
  This closes Debian bug #337972.

New API Features
----------------
* DGifSlurp() and EGifSpew() now preserve trailing extension blocks with
  no following image file, in an ExtensionBlockList member named 'Trailing'.
* DGifSlurp() and EGifSpew() now read and write interlaced images.
* The ExtensionBlock API has been repaired. The ExtensionBlockCount
  and ExtensionBlockList members of the SavedImage structures are no
  longer top-level in that structure, but now live in an
  ExtensionBlockList substructure named 'Leading'.  This was done so
  that the new list of trailing extension blocks in GifFileType can
  use the same list-handler code as the Leading extension-block list
  in each saved image.
* Six undocumented functions have been renamed; two of these take additional
  or slightly different argument types. See the Compatibility section of
  the library API documentation for details.
* Three documented functions - MakeMapObject(), FreeMapObject(), and
  UnionColorMap() - have been renamed to GifMakeMapObject(),
  GifFreeMapObject(), and GifUnionColorMap() respectively.  All
  functions exported by this library now have DGif, EGif, or Gif
  as a name prefix.
* New functions DGifSavedExtensionToGCB() and EGifGCBToSavedExtension()
  make it easy to read and edit GIF89 graphics control blocks in saved images.
* There's now an EGifGetGifVersion() that computes the version EGifSpew() 
  will write.
* QuantizeBuffer() has been returned to the core library as GifQuantizeBuffer() 
  - turns out some important applications (notably mplayer) were using it.
* TRUE and FALSE macros are gone, also VoidPtr.  No more namespace pollution.
* The library Draw* functions are now named GifDraw*. This fixes a conflict
  with the Windows API.
* Various arguments have been made const where possible.

Retirements
-----------
* The gifburst utility is gone.  Everybody has image viewers that
  can pan now, and removing it gets rid of a dependency on Perl.

Utilities
---------
* giftext displays the parsed contents of GIF89 graphics control blocks.
* icon2gif can both display and update GIF89 graphics control blocks.

I intend to release within a few days unless I'm alerted to some sort 
of blocker. I'll be adding a few more regression tests - that's the one
area of the project I'm not yet completely satisfied with.  

Please review and test the code.

Also, I'm taking suggestions for a project logo.  What image can we use to
represent GIFLIB?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Rapists just *love* unarmed women.  And the politicians who disarm them.

Re: [giflib-devel] Merging Debian 01-cve.patch ?

[Eric S. R. <es...@th...>]

Even Rouault <eve...@mi...>:
> did you consider merging http://patch-
> tracker.debian.org/patch/series/view/giflib/4.1.6-9/01-cve.patch that has been 
> in Debian (and perhaps many other distributions ) from a long time ? 

I'm merging it now, thanks.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[giflib-devel] Merging Debian 01-cve.patch ?

[Even R. <eve...@mi...>]

Hi,

did you consider merging http://patch-
tracker.debian.org/patch/series/view/giflib/4.1.6-9/01-cve.patch that has been 
in Debian (and perhaps many other distributions ) from a long time ? 

Best regards,

Even

[giflib-devel] I have shipped giflib-4.2.0 to SourceForge

[<es...@th...>]

Version 4.2.0
=============

Now maintained by ESR again after handoff by Toshio Kuratomi.

Code Fixes
----------
* Code updated internally to C99 to enable more correctness checks by
  the compiler. Compiles under GCC 4.6.1 without errors or warnings.
* A rare resource leak in the colormap-object maker was found with
  Coverity and fixed.
* The code now audits clean under Coverity and cppcheck.
* splint cleanup begun, there's a lot of work still to do on this.

New API Features
----------------
* The default GIF version to write is now computed at write time from
  the types of an image's extension blocks, but can be overridden with 
  EGifSetGifVersion().
* EGifSpew() is now thread-safe. 
* Two new functions, GifError() and GifErrorString(),
  return the error state in a form that can be used by programs.
* Two library functions - EGifOpenFileName() and EGifPutImageDesc() -
  now have bool rather than int flag arguments. Since bool is a
  typedef of int and TRUE/FALSE have been redefined to true/false, 
  both source and object compatibility with older library versions
  should be preserved. 
* GAGetArgs(), used only in the utilities, now returns bool rather
  than int. 
* The undocumented GIF_LIB_VERSION symbol is gone from the library header.  
  It has been replaced with three documented symbols: GIFLIB_MAJOR,
  GIFLIB_MINOR, and GIFLIB_RELEASE.

Retirements
-----------
* The gif2epsn and gif2iris utilities are gone.  They were full of
  platform dependencies for platforms long dead.  There are enough
  platform-independent GIF viewers in the world that these weren't
  adding any value. Removing these gets rid of a dependency on GL.
* The rle2gif, gif2rle, and gif2ps utilities are also gone. There are enough
  multiformat image converters in the world that these weren't adding 
  any value either.  Removing them reduces the codebase's dependencies.
* The gifburst utility is gone.  Everybody has image viewers that
  can pan now, and removing it gets rid of a dependency on Perl.
* The undocumented DumpScreen2Gif() is gone from the library.  The
  only non-obsolete capture mode it supported was through X, and that
  probably hasn't been used in years and is replaceable by any number
  of capture utilities.  Dropping this code makes the library's 
  portability issues go away.
* QuantizeBuffer(), GifQprintf(), PrintGifError(), GIF_ERROR() 
  and GIF_MESSAGE() have been removed from the core library.  
  They were used only by the utilities. QuantizeBuffer() has been
  inlined where it was used and the latter three are now part of the
  utility support library.
* The Game Boy Advanced test code is gone.  The platform was discontinued
  in 2008; more to the point, nobody ever documented the code's assumptions
  or expected results.
* The Changelog file is now retained for archival purposes only, and because
  autotools throws a hissy fit if there isn't one.  The single point of
  truth about changes and the reasons for them is the repository history.

Behavior changes
----------------
* The -q option of the utilities is replaced by an opposite -v (verbose)
  option; the default is now quiet for all platforms.  Defaulting to chattiness
  on MSDOS made sense in a world of slow text consoles, but not today.

Testing
-------
* There is now a proper regression-test suite; run 'make' in tests/.
  The old test-unx script is now tests/visual-check and can be run 
  occasionally for a check with the Mark One Eyeball.

Documentation
-------------
* Build instructions now live in build.txt
* An overview of the giflib API now lives in api.txt.
* Documentation is now in DocBook-XML, so either HTML or man pages can
  be generated from it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Don't ever think you know what's right for the other person.
He might start thinking he knows what's right for you.
	-- Paul Williams, `Das Energi'

[giflib-devel] Upcoming GIFLIB 4.2 release

[<es...@th...>]

I have fixed or disposed of every bug on the tracker, and done most of the 
items on 4.1.6's to-do list - the big exception being that I haven't
made the incompatible Version 5.0 API changes Toshio was contemplating.

I agree that nuking Make Extension() and adding a function code argument
to AddExtensionBlock() is the right way to go, but the time is not ripe.
I want to issue a bugfix release first, and plan to shortly as 4.2.

Here's what the NEWS file currently says:

Code Fixes
----------
* Code updated internally to C99 to enable more correctness checks by
  the compiler. Compiles under GCC 4.6.1 without errors or warnings.
* Code audits clean under cppcheck.
* splint cleanup begun, there's a lot of work still to do on this.

New API Features
----------------
* The default GIF version to write is now computed at write time from
  the types of an image's extension blocks, but can be overridden with 
  EGifSetGifVersion().
* EGifSpew() is now thread-safe. 
* Two new functions, GifError() and GifErrorString(),
  return the error state in a form that can be used by programs.
* Two library functions - EGifOpenFileName() and EGifPutImageDesc() -
  now have bool rather than int flag arguments. Since bool is a
  typedef of int and TRUE/FALSE have been redefined to true/false, 
  both source and object compatibility with older library versions
  should be preserved. 
* GAGetArgs(), used only in the utilities, now returns bool rather
  than int. 
* The undocumented GIF_LIB_VERSION symbol is gone from the library header.  
  It has been replaced with three documented symbols: GIFLIB_MAJOR,
  GIFLIB_MINOR, and GIFLIB_RELEASE.

Retirements
-----------
* The gif2epsn and gif2iris utilities are gone.  They were full of
  platform dependencies for platforms long dead.  There are enough
  platform-independent GIF viewers in the world that these weren't
  adding any value. Removing these gets rid of a dependency on GL.
* The rle2gif, gif2rle, and gif2ps utilities are also gone. There are enough
  multiformat image converters in the world that these weren't adding 
  any value either.  Removing them reduces the codebase's dependencies.
* The gifburst utility is gone.  Everybody has image viewers that
  can pan now, and removing it gets rid of a dependency on Perl.
* The undocumented DumpScreen2Gif() is gone from the library.  The
  only non-obsolete capture mode it supported was through X, and that
  probably hasn't been used in years and is replaceable by any number
  of capture utilities.  Dropping this code makes the library's 
  portability issues go away.
* QuantizeBuffer(), GifQprintf(), PrintGifError(), GIF_ERROR() 
  and GIF_MESSAGE() have been removed from the core library.  
  They were used only by the utilities. QuantizeBuffer() has been
  inlined where it was used and the latter three are now part of the
  utility support library.
* The Game Boy Advanced test code is gone.  The platform was discontinued
  in 2008; more to the point, nobody ever documented the code's assumptions
  or expected results.

Behavior changes
----------------
* The -q option of the utilities is replaced by an opposite -v (verbose)
  option; the default is now quiet for all platforms.  Defaulting to chattiness
  on MSDOS made sense in a world of slow text consoles, but not today.

Testing
-------
* There is now a proper regression-test suite; run 'make' in tests/.
  The old test-unx script is now tests/visual-check and can be run 
  occasionally for a check with the Mark One Eyeball.

Documentation
-------------
* Build instructions now live in build.txt
* An overview of the giflib API now lives in api.txt.
* Documentation is now in DocBook-XML, so either HTML or man pages can
  be generated from it.

This is that thorough dusting off I mentioned. :-) 

If you know of any must-fix issues, please tell me about them.
--
					>>esr>>

[giflib-devel] Repository head now includes a regression-test suite.

[<es...@th...>]

The repository head now includes a regression-test suite.  This
fixes the only high-priority bug on the tracker.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"One of the ordinary modes, by which tyrants accomplish their purposes
without resistance, is, by disarming the people, and making it an
offense to keep arms."
        -- Constitutional scholar and Supreme Court Justice Joseph Story, 1840

[giflib-devel] codebase passes cppcheck

[<es...@th...>]

The code passes cppcheck with only about half a dozen lines of
suppressions, all of false positives. (Checking this was one of the
objectives for which I rejoined.)  This code may be archaic, but
the quality is pretty good.

Full splint cleanup, on the other hand, is going to be quite a
pain in the ass.  I've barely made a start on it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"One of the ordinary modes, by which tyrants accomplish their purposes
without resistance, is, by disarming the people, and making it an
offense to keep arms."
        -- Constitutional scholar and Supreme Court Justice Joseph Story, 1840

Re: [giflib-devel] dropping Utah Raster Toolkit support

[Eric S. R. <es...@th...>]

Nguyễn Vũ Hưng <vuh...@gm...>:
> By "compete with ImageMagick", do you mean just to improving the conversion
> from and/to GIF format?

Yes.  My general point is that in 2012 I don't see any reason for
giflib to carry around a lot of conversion tools.  Doing so made some sense 
in the early 1990s because few other converters existed at all; now
there are so many that we can argue fine points about ImageMagick versus
GraphicsMagic, and that's before we go near anything like the GIMP.

> IMO, providing some format conversions and optimization (reduce size,
> quantization) for gif formats would be great.

What could we do that ImageMagick/GraphicsMagick can't do better?  One
of the two applications you mention are just its -resize option; the
other is +dither and -colors.  If we can't do a *better* job, why 
duplicate the effort?

The direction I'm definitely leaning in is to strip away duplicative
capabilities and focus hard on shipping clean, bulletproof library code.
I think that's what the world really wants from us.  But if someone can
come up with a good functional reason not to go minimalist like that, 
I'm listening.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [giflib-devel] dropping Utah Raster Toolkit support

[Nguyễn Vũ H. <vuh...@gm...>]

Hello,

On Tue, Apr 24, 2012 at 11:44, Eric S. Raymond <es...@th...> wrote:
> Is there any reason for us to compete with ImageMagick?  I'd be just
> as happy to let them own the file-format conversion problem and slim
> down our utility code.

If you have to, then consider competing with GraphicsMagick,which is a fork
of ImageMagick that is much well designed and faster than ImageMagick[1

By "compete with ImageMagick", do you mean just to improving the conversion
from and/to GIF format?

IM's users varies from who uses its APIs at (C or PHP) programming level, as
commmand line utilities while libgif serves a different set of users.

IMO, providing some format conversions and optimization (reduce size,
quantization) for
gif formats would be great.

Speaking of my own experience, I badly needed GIF quantization 3 years ago
(but not tnow)

Best regards,

Nguyen Vu Hung

[1] "GraphicsMagick is usually considerably faster at executing image
processing operations
from the command line than ImageMagick 6.5.8-10 is. One ImageMagick
algorithm runs as much
as 770 times slower. GraphicsMagick clearly runs much more efficiently
under Microsoft Windows."
http://www.graphicsmagick.org/benchmarks.html


-- 
Best Regards,
Nguyen Hung Vu [aka: NVH] ( in Vietnamese: Nguyễn Vũ Hưng )
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype:
vuhung16plus, twitter: vuhung, MSN: vuhung16.
http://www.facebook.com/nguyenvuhung
http://nguyen-vu-hung.blogspot.com/
Học tiếng Nhật: http://hoc-tiengnhat.blogspot.com/
Vietnamese LibreOffice: http://libo-vi.blogspot.com/
Mozilla & Firefox tiếng Việt: http://mozilla-vi.blogspot.com/

Disclaimer: When posted to social networking groups include, but not
limited Linux Users' Groups,
Free and Open Sources forums, mailing lists, the obove is my personal
opinion and is *not*
the opinion of my employer(s), associations and/or groups I join.

[giflib-devel] dropping Utah Raster Toolkit support

[<es...@th...>]

Is there any reason for us to compete with ImageMagick?  I'd be just
as happy to let them own the file-format conversion problem and slim
down our utility code.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The right to buy weapons is the right to be free.
        -- A.E. Van Vogt, "The Weapon Shops Of Isher", ASF December 1942

[giflib-devel] State of the giflib code - what else can I remove?

[<es...@th...>]

The giflib codebase badly needed to be brought into the 21st century.
Significant portions of it were obsolete and a maintainance burden, and
the C it was written in was a rather archaic dialect tangled with platform
#ifdefs - so old that it didn't rely on having void * or fixed-width types.  

I've already fixed a lot of the more obvious problems simply by
ripping out a lot of obsolescent code.  C99 and Single Unix
Specification give us better ways to do cross-platform things that
used to take a lot of platform-specific headers. I've also dropped
a couple of utilities, gif2epsn and gif2iris, that targeted obsolete
hardware.

The only potentially user-visible change to the library so far is that
the undocumented DumpScreen2Gif() entry point is gone.  Most of that
code was certainly obsolete, targeting things like EGA graphic cards
(!).  Only the X case might still have worked, and I'm doubtful about
even that much.  Ripping it out solved about 80% of the remaining
portability problems.

The remaining 20% are concentrated in a small number of files that
I'm wondering if I should just drop. 

1, gif2x11.  Do we really need to carry an X viewer in the  giflib 
distribution?  There are enough of those that I'm inclined to let
that be somebody else's problem.

2. The Game Boy Advanced support.  What's up with that?  Was it ever
documented? The product was discontinued in 2008 - is there any reason
to consider it relevant to future giflib releases?

3. The files in the windows/ directory.  Where are these documented?  
Why are we carrying them?  I see the code dates from 1999; is there
any reason to believe anyone is still using it?
--
						>>esr>>

[giflib-devel] Plans for giflib

[<es...@th...>]

As Toshio notes, I have agreed to resume the leadership of this
project.  After a gap of eighteen years!

I do not have super-ambitions plans for giflib.  My main goal in
rejoining is to give the code a correctness audit using tools
such as splint and cppcheck, clean up compiler warnings, and
generally give the code a good thorough dusting.  I'm also going
to look into creating a proper regression-test suite and improving
the documentation.

Thinhs I've already done in the repo include (a) changing all uses of 
sprintf(3) to snprint(3), and (b) changing the utilities so they
use C99 bool internally rather than old-fashioned TRUE and FALSE
macros.  The goal in both cases is to enable auditing tools to do
tighter checks of static correctness and type safety.

I also plan a pass through the tracker to knock out outstanding bugs.
Most should be easy to fix with a little elbow grease.
--
				>>esr>>

[giflib-devel] Eric S. Raymond to take up maintainance of giflib

[Toshio K. <a.b...@gm...>]

Those who can remember back far enough (or have read the source code) may
know that Eric S. Raymond was once the maintainer of giflib. He handed it
off to me when I started developing libungif as an LZW-compressor-free
version to work around the Unisys patents.

Over time, though, things change.  The LZW patent expired.  giflib and
libungif were merged back together.  And I stopped using C for my coding.
It no longer makes sense for me to maintain giflib (and hasn't for a while)
since I don't use it at all.  So I'm very happy to announce that esr has
agreed to resume maintaining giflib, merging patches, adding new features,
and making new releases.  I expect this to result in giflib getting more
love than it has for the past decade or so ;-)

Best wishes to all the giflib users and developers, may your future be
filled with dancing pixel art ;-)

-Toshio

Re: [giflib-devel] Help using gif library

[Toshio K. <a.b...@gm...>]

On Mon, Jun 27, 2011 at 11:10:18PM +0530, Smriti Agarwal wrote:
> 
> 
> 
> 
> Hello
> 
> I am working on a project  that includes reading and writing of gif images. For
> opening the file i have simply called the method DGifOpenFile() which itself
> calls DGifOpenFileHandle() and DGifGetScreeanDesc() methods. After this method
> call when i call DGifGetRecordType() or any other method it gets stuck in an
> infinite loop as no error message is printed the process continues to be
> working, which requires manual interruption. I even tried accessing screen
> description components of GifFileType struct but the same thing happens.
>   I have been trying to understand and sort this out for long, but could find
> no probable reason for this. My project is in C++.
> 
> Please help me solve and understand this problem. Looking forward to the reply.
> 
I've been trying to give away maintainership of giflib for years but no
one's really picked it up and run with it.  If you're just getting started
with some new code, I'd recommend trying out another library.  For instance,
my impression is that gd is better maintained:

https://bitbucket.org/pierrejoye/gd-libgd/overview

-Toshio Kuratomi

[giflib-devel] Help using gif library

[Smriti A. <smr...@gm...>]

Hello

I am working on a project  that includes reading and writing of gif images.
For opening the file i have simply called the method DGifOpenFile() which
itself calls DGifOpenFileHandle() and DGifGetScreeanDesc() methods. After
this method call when i call DGifGetRecordType() or any other method it gets
stuck in an infinite loop as no error message is printed the process
continues to be working, which requires manual interruption. I even tried
accessing screen description components of GifFileType struct but the same
thing happens.
  I have been trying to understand and sort this out for long, but could
find no probable reason for this. My project is in C++.

Please help me solve and understand this problem. Looking forward to the
reply.

Thanks.




-- 
Smriti

[giflib-devel] Fwd: Help using gif library

[Smriti A. <smr...@gm...>]

---------- Forwarded message ----------
From: Smriti Agarwal <smr...@gm...>
Date: Sat, Jun 25, 2011 at 12:54 AM
Subject: Help using gif library
To: gif...@li...


Hello

I am working on a project  that includes reading and writing of gif images.
For opening the file i have simply called the method DGifOpenFile() which
itself calls DGifOpenFileHandle() and DGifGetScreeanDesc() methods. After
this method call when i call DGifGetRecordType() or any other method it gets
stuck in an infinite loop as no error message is printed the process
continues to be working, which requires manual interruption. I even tried
accessing screen description components of GifFileType struct but the same
thing happens.
  I have been trying to understand and sort this out for long, but could
find no probable reason for this. My project is in C++.

Please help me solve and understand this problem. Looking forward to the
reply.

Thanks.
-- 
Smriti



-- 
Smriti