mirror of
https://github.com/aaronsgiles/JPEGView.git
synced 2024-06-01 03:41:27 +00:00
1 line
37 KiB
C
1 line
37 KiB
C
|
/*
* jmemmgr.c
*
* Copyright (C) 1991-1994, Thomas G. Lane.
* This file is part of the Independent JPEG Group's software.
* For conditions of distribution and use, see the accompanying README file.
*
* This file contains the JPEG system-independent memory management
* routines. This code is usable across a wide variety of machines; most
* of the system dependencies have been isolated in a separate file.
* The major functions provided here are:
* * pool-based allocation and freeing of memory;
* * policy decisions about how to divide available memory among the
* virtual arrays;
* * control logic for swapping virtual arrays between main memory and
* backing storage.
* The separate system-dependent file provides the actual backing-storage
* access code, and it contains the policy decision about how much total
* main memory to use.
* This file is system-dependent in the sense that some of its functions
* are unnecessary in some systems. For example, if there is enough virtual
* memory so that backing storage will never be used, much of the virtual
* array control logic could be removed. (Of course, if you have that much
* memory then you shouldn't care about a little bit of unused code...)
*/
#define JPEG_INTERNALS
#define AM_MEMORY_MANAGER /* we define jvirt_Xarray_control structs */
#include "jinclude.h"
#include "jpeglib.h"
#include "jmemsys.h" /* import the system-dependent declarations */
#ifndef NO_GETENV
#ifndef HAVE_STDLIB_H /* <stdlib.h> should declare getenv() */
extern char * getenv JPP((const char * name));
#endif
#endif
/*
* Some important notes:
* The allocation routines provided here must never return NULL.
* They should exit to error_exit if unsuccessful.
*
* It's not a good idea to try to merge the sarray and barray routines,
* even though they are textually almost the same, because samples are
* usually stored as bytes while coefficients are shorts or ints. Thus,
* in machines where byte pointers have a different representation from
* word pointers, the resulting machine code could not be the same.
*/
/*
* Many machines require storage alignment: longs must start on 4-byte
* boundaries, doubles on 8-byte boundaries, etc. On such machines, malloc()
* always returns pointers that are multiples of the worst-case alignment
* requirement, and we had better do so too.
* There isn't any really portable way to determine the worst-case alignment
* requirement. This code assumes that the alignment requirement is
* multiples of SIZEOF(align_type). Here we define align_type as double;
* with this definition, the code will run on all machines known to me.
* If your machine has lesser alignment needs, you can save a few bytes
* by making align_type smaller.
*/
typedef double align_type;
/*
* We allocate objects from "pools", where each pool is gotten with a single
* request to jpeg_get_small() or jpeg_get_large(). There is no per-object
* overhead within a pool, except for alignment padding. Each pool has a
* header with a link to the next pool of the same class.
* Small and large pool headers are identical except that the latter's
* link pointer must be FAR on 80x86 machines.
* Notice that the "real" header fields are union'ed with a dummy align_type
* field. This forces the compiler to make SIZEOF(small_pool_hdr) a multiple
* of the alignment requirement of align_type.
*/
typedef union small_pool_struct * small_pool_ptr;
typedef union small_pool_struct {
struct {
small_pool_ptr next; /* next in list of pools */
size_t bytes_used; /* how many bytes already used within pool */
size_t bytes_left; /* bytes still available in this pool */
} hdr;
align_type dummy; /* included in union to ensure alignment */
} small_pool_hdr;
typedef union large_pool_struct FAR * large_pool_ptr;
typedef union large_pool_struct {
struct {
large_pool_ptr next; /* next in list of pools */
size_t bytes_used; /* how many bytes already used within pool */
size_t bytes_left; /* bytes still available in this
|