Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Date: Fri, 2 Feb 2001 09:21:58 -0800 (PST)
From: Thomas Boutell <boutell AT vader DOT boutell DOT com>
To: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
cc: "Dr. Volker Zell" <Dr DOT Volker DOT Zell AT oracle DOT com>, cygwin-apps AT cygwin DOT com
Subject: Re: error compiling gd-1.8.3 under cygwin-1.1.7
In-Reply-To: <3A7A6641.2534253B@ece.gatech.edu>
Message-ID: <Pine.LNX.3.95.1010202091628.2121G-100000@vader.boutell.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 2 Feb 2001, Charles S. Wilson wrote:

> Hmmm...then your app (gd ?) was probably accessing private fields that
> were subject to modification -- as Ken puts it below, "playing with
> fire."  Progressive mode isn't gone, but how it is handled internally is
> different:
>   before : cinfo->progressive_mode   
>            was a "boolean" (int)
>   with lj: cinfo->process is a int that takes one 
>            of several values (e.g. JPROC_PROGRESSIVE)
> Again, this is all handled *inside* the private area of libjpeg.  It
> really shouldn't break your program unless your program was doing
> naughty things, like messing with internal data structures.

Why is this structure in the publicly exported 'jpeglib.h' if 
it isn't safe to inspect it? Just curious. The fella who wrote
the (quick and dirty, but useful) jpeg support for gd probably
looked at the words "this file defines the application interface
for the JPEG library" and got a warm, fuzzy feeling.

In this case, gd is trying to determine whether the JPEG it is
currently loading is progressively stored or not, in order to 
set gd's own interlace flag so that the same behavior can be
maintained when the image is saved again. A good idea, but is
there a safe way to get that information? If not, we're
probably better off removing this little featurelet to gain
greater compatibility with other versions of libjpeg.

The /* Remaining fields should be treated as private by applications. */
message appears in the middle of the jpeg_component_info structure.
It doesn't appear to be relevant to the rest of the file; I wouldn't
have read it that way before reading your message.

I'm not criticizing the generally fabulous jpeg library or the
generous work of its authors; just pointing out that it would be
quite difficult for most programmers to figure out that there
was anything unwise about inspecting the progressive_mode boolean.
I suppose it's academic at this point. We should probably
just yank that feature. 

In any case, JPEG loading in gd is fairly vestigial until
a truecolor gd emerges.

--
Thomas Boutell
Boutell.Com, Inc.                                       
http://www.boutell.com/