Path: blob/master/Utilities/cmliblzma/liblzma/api/lzma/base.h
3158 views
/* SPDX-License-Identifier: 0BSD */12/**3* \file lzma/base.h4* \brief Data types and functions used in many places in liblzma API5* \note Never include this file directly. Use <lzma.h> instead.6*/78/*9* Author: Lasse Collin10*/1112#ifndef LZMA_H_INTERNAL13# error Never include this file directly. Use <lzma.h> instead.14#endif151617/**18* \brief Boolean19*20* This is here because C89 doesn't have stdbool.h. To set a value for21* variables having type lzma_bool, you can use22* - C99's 'true' and 'false' from stdbool.h;23* - C++'s internal 'true' and 'false'; or24* - integers one (true) and zero (false).25*/26typedef unsigned char lzma_bool;272829/**30* \brief Type of reserved enumeration variable in structures31*32* To avoid breaking library ABI when new features are added, several33* structures contain extra variables that may be used in future. Since34* sizeof(enum) can be different than sizeof(int), and sizeof(enum) may35* even vary depending on the range of enumeration constants, we specify36* a separate type to be used for reserved enumeration variables. All37* enumeration constants in liblzma API will be non-negative and less38* than 128, which should guarantee that the ABI won't break even when39* new constants are added to existing enumerations.40*/41typedef enum {42LZMA_RESERVED_ENUM = 043} lzma_reserved_enum;444546/**47* \brief Return values used by several functions in liblzma48*49* Check the descriptions of specific functions to find out which return50* values they can return. With some functions the return values may have51* more specific meanings than described here; those differences are52* described per-function basis.53*/54typedef enum {55LZMA_OK = 0,56/**<57* \brief Operation completed successfully58*/5960LZMA_STREAM_END = 1,61/**<62* \brief End of stream was reached63*64* In encoder, LZMA_SYNC_FLUSH, LZMA_FULL_FLUSH, or65* LZMA_FINISH was finished. In decoder, this indicates66* that all the data was successfully decoded.67*68* In all cases, when LZMA_STREAM_END is returned, the last69* output bytes should be picked from strm->next_out.70*/7172LZMA_NO_CHECK = 2,73/**<74* \brief Input stream has no integrity check75*76* This return value can be returned only if the77* LZMA_TELL_NO_CHECK flag was used when initializing78* the decoder. LZMA_NO_CHECK is just a warning, and79* the decoding can be continued normally.80*81* It is possible to call lzma_get_check() immediately after82* lzma_code has returned LZMA_NO_CHECK. The result will83* naturally be LZMA_CHECK_NONE, but the possibility to call84* lzma_get_check() may be convenient in some applications.85*/8687LZMA_UNSUPPORTED_CHECK = 3,88/**<89* \brief Cannot calculate the integrity check90*91* The usage of this return value is different in encoders92* and decoders.93*94* Encoders can return this value only from the initialization95* function. If initialization fails with this value, the96* encoding cannot be done, because there's no way to produce97* output with the correct integrity check.98*99* Decoders can return this value only from lzma_code() and100* only if the LZMA_TELL_UNSUPPORTED_CHECK flag was used when101* initializing the decoder. The decoding can still be102* continued normally even if the check type is unsupported,103* but naturally the check will not be validated, and possible104* errors may go undetected.105*106* With decoder, it is possible to call lzma_get_check()107* immediately after lzma_code() has returned108* LZMA_UNSUPPORTED_CHECK. This way it is possible to find109* out what the unsupported Check ID was.110*/111112LZMA_GET_CHECK = 4,113/**<114* \brief Integrity check type is now available115*116* This value can be returned only by the lzma_code() function117* and only if the decoder was initialized with the118* LZMA_TELL_ANY_CHECK flag. LZMA_GET_CHECK tells the119* application that it may now call lzma_get_check() to find120* out the Check ID. This can be used, for example, to121* implement a decoder that accepts only files that have122* strong enough integrity check.123*/124125LZMA_MEM_ERROR = 5,126/**<127* \brief Cannot allocate memory128*129* Memory allocation failed, or the size of the allocation130* would be greater than SIZE_MAX.131*132* Due to internal implementation reasons, the coding cannot133* be continued even if more memory were made available after134* LZMA_MEM_ERROR.135*/136137LZMA_MEMLIMIT_ERROR = 6,138/**<139* \brief Memory usage limit was reached140*141* Decoder would need more memory than allowed by the142* specified memory usage limit. To continue decoding,143* the memory usage limit has to be increased with144* lzma_memlimit_set().145*146* liblzma 5.2.6 and earlier had a bug in single-threaded .xz147* decoder (lzma_stream_decoder()) which made it impossible148* to continue decoding after LZMA_MEMLIMIT_ERROR even if149* the limit was increased using lzma_memlimit_set().150* Other decoders worked correctly.151*/152153LZMA_FORMAT_ERROR = 7,154/**<155* \brief File format not recognized156*157* The decoder did not recognize the input as supported file158* format. This error can occur, for example, when trying to159* decode .lzma format file with lzma_stream_decoder,160* because lzma_stream_decoder accepts only the .xz format.161*/162163LZMA_OPTIONS_ERROR = 8,164/**<165* \brief Invalid or unsupported options166*167* Invalid or unsupported options, for example168* - unsupported filter(s) or filter options; or169* - reserved bits set in headers (decoder only).170*171* Rebuilding liblzma with more features enabled, or172* upgrading to a newer version of liblzma may help.173*/174175LZMA_DATA_ERROR = 9,176/**<177* \brief Data is corrupt178*179* The usage of this return value is different in encoders180* and decoders. In both encoder and decoder, the coding181* cannot continue after this error.182*183* Encoders return this if size limits of the target file184* format would be exceeded. These limits are huge, thus185* getting this error from an encoder is mostly theoretical.186* For example, the maximum compressed and uncompressed187* size of a .xz Stream is roughly 8 EiB (2^63 bytes).188*189* Decoders return this error if the input data is corrupt.190* This can mean, for example, invalid CRC32 in headers191* or invalid check of uncompressed data.192*/193194LZMA_BUF_ERROR = 10,195/**<196* \brief No progress is possible197*198* This error code is returned when the coder cannot consume199* any new input and produce any new output. The most common200* reason for this error is that the input stream being201* decoded is truncated or corrupt.202*203* This error is not fatal. Coding can be continued normally204* by providing more input and/or more output space, if205* possible.206*207* Typically the first call to lzma_code() that can do no208* progress returns LZMA_OK instead of LZMA_BUF_ERROR. Only209* the second consecutive call doing no progress will return210* LZMA_BUF_ERROR. This is intentional.211*212* With zlib, Z_BUF_ERROR may be returned even if the213* application is doing nothing wrong, so apps will need214* to handle Z_BUF_ERROR specially. The above hack215* guarantees that liblzma never returns LZMA_BUF_ERROR216* to properly written applications unless the input file217* is truncated or corrupt. This should simplify the218* applications a little.219*/220221LZMA_PROG_ERROR = 11,222/**<223* \brief Programming error224*225* This indicates that the arguments given to the function are226* invalid or the internal state of the decoder is corrupt.227* - Function arguments are invalid or the structures228* pointed by the argument pointers are invalid229* e.g. if strm->next_out has been set to NULL and230* strm->avail_out > 0 when calling lzma_code().231* - lzma_* functions have been called in wrong order232* e.g. lzma_code() was called right after lzma_end().233* - If errors occur randomly, the reason might be flaky234* hardware.235*236* If you think that your code is correct, this error code237* can be a sign of a bug in liblzma. See the documentation238* how to report bugs.239*/240241LZMA_SEEK_NEEDED = 12,242/**<243* \brief Request to change the input file position244*245* Some coders can do random access in the input file. The246* initialization functions of these coders take the file size247* as an argument. No other coders can return LZMA_SEEK_NEEDED.248*249* When this value is returned, the application must seek to250* the file position given in lzma_stream.seek_pos. This value251* is guaranteed to never exceed the file size that was252* specified at the coder initialization.253*254* After seeking the application should read new input and255* pass it normally via lzma_stream.next_in and .avail_in.256*/257258/*259* These enumerations may be used internally by liblzma260* but they will never be returned to applications.261*/262LZMA_RET_INTERNAL1 = 101,263LZMA_RET_INTERNAL2 = 102,264LZMA_RET_INTERNAL3 = 103,265LZMA_RET_INTERNAL4 = 104,266LZMA_RET_INTERNAL5 = 105,267LZMA_RET_INTERNAL6 = 106,268LZMA_RET_INTERNAL7 = 107,269LZMA_RET_INTERNAL8 = 108270} lzma_ret;271272273/**274* \brief The 'action' argument for lzma_code()275*276* After the first use of LZMA_SYNC_FLUSH, LZMA_FULL_FLUSH, LZMA_FULL_BARRIER,277* or LZMA_FINISH, the same 'action' must be used until lzma_code() returns278* LZMA_STREAM_END. Also, the amount of input (that is, strm->avail_in) must279* not be modified by the application until lzma_code() returns280* LZMA_STREAM_END. Changing the 'action' or modifying the amount of input281* will make lzma_code() return LZMA_PROG_ERROR.282*/283typedef enum {284LZMA_RUN = 0,285/**<286* \brief Continue coding287*288* Encoder: Encode as much input as possible. Some internal289* buffering will probably be done (depends on the filter290* chain in use), which causes latency: the input used won't291* usually be decodeable from the output of the same292* lzma_code() call.293*294* Decoder: Decode as much input as possible and produce as295* much output as possible.296*/297298LZMA_SYNC_FLUSH = 1,299/**<300* \brief Make all the input available at output301*302* Normally the encoder introduces some latency.303* LZMA_SYNC_FLUSH forces all the buffered data to be304* available at output without resetting the internal305* state of the encoder. This way it is possible to use306* compressed stream for example for communication over307* network.308*309* Only some filters support LZMA_SYNC_FLUSH. Trying to use310* LZMA_SYNC_FLUSH with filters that don't support it will311* make lzma_code() return LZMA_OPTIONS_ERROR. For example,312* LZMA1 doesn't support LZMA_SYNC_FLUSH but LZMA2 does.313*314* Using LZMA_SYNC_FLUSH very often can dramatically reduce315* the compression ratio. With some filters (for example,316* LZMA2), fine-tuning the compression options may help317* mitigate this problem significantly (for example,318* match finder with LZMA2).319*320* Decoders don't support LZMA_SYNC_FLUSH.321*/322323LZMA_FULL_FLUSH = 2,324/**<325* \brief Finish encoding of the current Block326*327* All the input data going to the current Block must have328* been given to the encoder (the last bytes can still be329* pending in *next_in). Call lzma_code() with LZMA_FULL_FLUSH330* until it returns LZMA_STREAM_END. Then continue normally331* with LZMA_RUN or finish the Stream with LZMA_FINISH.332*333* This action is currently supported only by Stream encoder334* and easy encoder (which uses Stream encoder). If there is335* no unfinished Block, no empty Block is created.336*/337338LZMA_FULL_BARRIER = 4,339/**<340* \brief Finish encoding of the current Block341*342* This is like LZMA_FULL_FLUSH except that this doesn't343* necessarily wait until all the input has been made344* available via the output buffer. That is, lzma_code()345* might return LZMA_STREAM_END as soon as all the input346* has been consumed (avail_in == 0).347*348* LZMA_FULL_BARRIER is useful with a threaded encoder if349* one wants to split the .xz Stream into Blocks at specific350* offsets but doesn't care if the output isn't flushed351* immediately. Using LZMA_FULL_BARRIER allows keeping352* the threads busy while LZMA_FULL_FLUSH would make353* lzma_code() wait until all the threads have finished354* until more data could be passed to the encoder.355*356* With a lzma_stream initialized with the single-threaded357* lzma_stream_encoder() or lzma_easy_encoder(),358* LZMA_FULL_BARRIER is an alias for LZMA_FULL_FLUSH.359*/360361LZMA_FINISH = 3362/**<363* \brief Finish the coding operation364*365* All the input data must have been given to the encoder366* (the last bytes can still be pending in next_in).367* Call lzma_code() with LZMA_FINISH until it returns368* LZMA_STREAM_END. Once LZMA_FINISH has been used,369* the amount of input must no longer be changed by370* the application.371*372* When decoding, using LZMA_FINISH is optional unless the373* LZMA_CONCATENATED flag was used when the decoder was374* initialized. When LZMA_CONCATENATED was not used, the only375* effect of LZMA_FINISH is that the amount of input must not376* be changed just like in the encoder.377*/378} lzma_action;379380381/**382* \brief Custom functions for memory handling383*384* A pointer to lzma_allocator may be passed via lzma_stream structure385* to liblzma, and some advanced functions take a pointer to lzma_allocator386* as a separate function argument. The library will use the functions387* specified in lzma_allocator for memory handling instead of the default388* malloc() and free(). C++ users should note that the custom memory389* handling functions must not throw exceptions.390*391* Single-threaded mode only: liblzma doesn't make an internal copy of392* lzma_allocator. Thus, it is OK to change these function pointers in393* the middle of the coding process, but obviously it must be done394* carefully to make sure that the replacement 'free' can deallocate395* memory allocated by the earlier 'alloc' function(s).396*397* Multithreaded mode: liblzma might internally store pointers to the398* lzma_allocator given via the lzma_stream structure. The application399* must not change the allocator pointer in lzma_stream or the contents400* of the pointed lzma_allocator structure until lzma_end() has been used401* to free the memory associated with that lzma_stream. The allocation402* functions might be called simultaneously from multiple threads, and403* thus they must be thread safe.404*/405typedef struct {406/**407* \brief Pointer to a custom memory allocation function408*409* If you don't want a custom allocator, but still want410* custom free(), set this to NULL and liblzma will use411* the standard malloc().412*413* \param opaque lzma_allocator.opaque (see below)414* \param nmemb Number of elements like in calloc(). liblzma415* will always set nmemb to 1, so it is safe to416* ignore nmemb in a custom allocator if you like.417* The nmemb argument exists only for418* compatibility with zlib and libbzip2.419* \param size Size of an element in bytes.420* liblzma never sets this to zero.421*422* \return Pointer to the beginning of a memory block of423* 'size' bytes, or NULL if allocation fails424* for some reason. When allocation fails, functions425* of liblzma return LZMA_MEM_ERROR.426*427* The allocator should not waste time zeroing the allocated buffers.428* This is not only about speed, but also memory usage, since the429* operating system kernel doesn't necessarily allocate the requested430* memory in physical memory until it is actually used. With small431* input files, liblzma may actually need only a fraction of the432* memory that it requested for allocation.433*434* \note LZMA_MEM_ERROR is also used when the size of the435* allocation would be greater than SIZE_MAX. Thus,436* don't assume that the custom allocator must have437* returned NULL if some function from liblzma438* returns LZMA_MEM_ERROR.439*/440void *(LZMA_API_CALL *alloc)(void *opaque, size_t nmemb, size_t size);441442/**443* \brief Pointer to a custom memory freeing function444*445* If you don't want a custom freeing function, but still446* want a custom allocator, set this to NULL and liblzma447* will use the standard free().448*449* \param opaque lzma_allocator.opaque (see below)450* \param ptr Pointer returned by lzma_allocator.alloc(),451* or when it is set to NULL, a pointer returned452* by the standard malloc().453*/454void (LZMA_API_CALL *free)(void *opaque, void *ptr);455456/**457* \brief Pointer passed to .alloc() and .free()458*459* opaque is passed as the first argument to lzma_allocator.alloc()460* and lzma_allocator.free(). This intended to ease implementing461* custom memory allocation functions for use with liblzma.462*463* If you don't need this, you should set this to NULL.464*/465void *opaque;466467} lzma_allocator;468469470/**471* \brief Internal data structure472*473* The contents of this structure is not visible outside the library.474*/475typedef struct lzma_internal_s lzma_internal;476477478/**479* \brief Passing data to and from liblzma480*481* The lzma_stream structure is used for482* - passing pointers to input and output buffers to liblzma;483* - defining custom memory handler functions; and484* - holding a pointer to coder-specific internal data structures.485*486* Typical usage:487*488* - After allocating lzma_stream (on stack or with malloc()), it must be489* initialized to LZMA_STREAM_INIT (see LZMA_STREAM_INIT for details).490*491* - Initialize a coder to the lzma_stream, for example by using492* lzma_easy_encoder() or lzma_auto_decoder(). Some notes:493* - In contrast to zlib, strm->next_in and strm->next_out are494* ignored by all initialization functions, thus it is safe495* to not initialize them yet.496* - The initialization functions always set strm->total_in and497* strm->total_out to zero.498* - If the initialization function fails, no memory is left allocated499* that would require freeing with lzma_end() even if some memory was500* associated with the lzma_stream structure when the initialization501* function was called.502*503* - Use lzma_code() to do the actual work.504*505* - Once the coding has been finished, the existing lzma_stream can be506* reused. It is OK to reuse lzma_stream with different initialization507* function without calling lzma_end() first. Old allocations are508* automatically freed.509*510* - Finally, use lzma_end() to free the allocated memory. lzma_end() never511* frees the lzma_stream structure itself.512*513* Application may modify the values of total_in and total_out as it wants.514* They are updated by liblzma to match the amount of data read and515* written but aren't used for anything else except as a possible return516* values from lzma_get_progress().517*/518typedef struct {519const uint8_t *next_in; /**< Pointer to the next input byte. */520size_t avail_in; /**< Number of available input bytes in next_in. */521uint64_t total_in; /**< Total number of bytes read by liblzma. */522523uint8_t *next_out; /**< Pointer to the next output position. */524size_t avail_out; /**< Amount of free space in next_out. */525uint64_t total_out; /**< Total number of bytes written by liblzma. */526527/**528* \brief Custom memory allocation functions529*530* In most cases this is NULL which makes liblzma use531* the standard malloc() and free().532*533* \note In 5.0.x this is not a const pointer.534*/535const lzma_allocator *allocator;536537/** Internal state is not visible to applications. */538lzma_internal *internal;539540/*541* Reserved space to allow possible future extensions without542* breaking the ABI. Excluding the initialization of this structure,543* you should not touch these, because the names of these variables544* may change.545*/546547/** \private Reserved member. */548void *reserved_ptr1;549550/** \private Reserved member. */551void *reserved_ptr2;552553/** \private Reserved member. */554void *reserved_ptr3;555556/** \private Reserved member. */557void *reserved_ptr4;558559/**560* \brief New seek input position for LZMA_SEEK_NEEDED561*562* When lzma_code() returns LZMA_SEEK_NEEDED, the new input position563* needed by liblzma will be available seek_pos. The value is564* guaranteed to not exceed the file size that was specified when565* this lzma_stream was initialized.566*567* In all other situations the value of this variable is undefined.568*/569uint64_t seek_pos;570571/** \private Reserved member. */572uint64_t reserved_int2;573574/** \private Reserved member. */575size_t reserved_int3;576577/** \private Reserved member. */578size_t reserved_int4;579580/** \private Reserved member. */581lzma_reserved_enum reserved_enum1;582583/** \private Reserved member. */584lzma_reserved_enum reserved_enum2;585586} lzma_stream;587588589/**590* \brief Initialization for lzma_stream591*592* When you declare an instance of lzma_stream, you can immediately593* initialize it so that initialization functions know that no memory594* has been allocated yet:595*596* lzma_stream strm = LZMA_STREAM_INIT;597*598* If you need to initialize a dynamically allocated lzma_stream, you can use599* memset(strm_pointer, 0, sizeof(lzma_stream)). Strictly speaking, this600* violates the C standard since NULL may have different internal601* representation than zero, but it should be portable enough in practice.602* Anyway, for maximum portability, you can use something like this:603*604* lzma_stream tmp = LZMA_STREAM_INIT;605* *strm = tmp;606*/607#define LZMA_STREAM_INIT \608{ NULL, 0, 0, NULL, 0, 0, NULL, NULL, \609NULL, NULL, NULL, NULL, 0, 0, 0, 0, \610LZMA_RESERVED_ENUM, LZMA_RESERVED_ENUM }611612613/**614* \brief Encode or decode data615*616* Once the lzma_stream has been successfully initialized (e.g. with617* lzma_stream_encoder()), the actual encoding or decoding is done618* using this function. The application has to update strm->next_in,619* strm->avail_in, strm->next_out, and strm->avail_out to pass input620* to and get output from liblzma.621*622* See the description of the coder-specific initialization function to find623* out what 'action' values are supported by the coder.624*625* \param strm Pointer to lzma_stream that is at least initialized626* with LZMA_STREAM_INIT.627* \param action Action for this function to take. Must be a valid628* lzma_action enum value.629*630* \return Any valid lzma_ret. See the lzma_ret enum description for more631* information.632*/633extern LZMA_API(lzma_ret) lzma_code(lzma_stream *strm, lzma_action action)634lzma_nothrow lzma_attr_warn_unused_result;635636637/**638* \brief Free memory allocated for the coder data structures639*640* After lzma_end(strm), strm->internal is guaranteed to be NULL. No other641* members of the lzma_stream structure are touched.642*643* \note zlib indicates an error if application end()s unfinished644* stream structure. liblzma doesn't do this, and assumes that645* application knows what it is doing.646*647* \param strm Pointer to lzma_stream that is at least initialized648* with LZMA_STREAM_INIT.649*/650extern LZMA_API(void) lzma_end(lzma_stream *strm) lzma_nothrow;651652653/**654* \brief Get progress information655*656* In single-threaded mode, applications can get progress information from657* strm->total_in and strm->total_out. In multi-threaded mode this is less658* useful because a significant amount of both input and output data gets659* buffered internally by liblzma. This makes total_in and total_out give660* misleading information and also makes the progress indicator updates661* non-smooth.662*663* This function gives realistic progress information also in multi-threaded664* mode by taking into account the progress made by each thread. In665* single-threaded mode *progress_in and *progress_out are set to666* strm->total_in and strm->total_out, respectively.667*668* \param strm Pointer to lzma_stream that is at least669* initialized with LZMA_STREAM_INIT.670* \param[out] progress_in Pointer to the number of input bytes processed.671* \param[out] progress_out Pointer to the number of output bytes processed.672*/673extern LZMA_API(void) lzma_get_progress(lzma_stream *strm,674uint64_t *progress_in, uint64_t *progress_out) lzma_nothrow;675676677/**678* \brief Get the memory usage of decoder filter chain679*680* This function is currently supported only when *strm has been initialized681* with a function that takes a memlimit argument. With other functions, you682* should use e.g. lzma_raw_encoder_memusage() or lzma_raw_decoder_memusage()683* to estimate the memory requirements.684*685* This function is useful e.g. after LZMA_MEMLIMIT_ERROR to find out how big686* the memory usage limit should have been to decode the input. Note that687* this may give misleading information if decoding .xz Streams that have688* multiple Blocks, because each Block can have different memory requirements.689*690* \param strm Pointer to lzma_stream that is at least initialized691* with LZMA_STREAM_INIT.692*693* \return How much memory is currently allocated for the filter694* decoders. If no filter chain is currently allocated,695* some non-zero value is still returned, which is less than696* or equal to what any filter chain would indicate as its697* memory requirement.698*699* If this function isn't supported by *strm or some other error700* occurs, zero is returned.701*/702extern LZMA_API(uint64_t) lzma_memusage(const lzma_stream *strm)703lzma_nothrow lzma_attr_pure;704705706/**707* \brief Get the current memory usage limit708*709* This function is supported only when *strm has been initialized with710* a function that takes a memlimit argument.711*712* \param strm Pointer to lzma_stream that is at least initialized713* with LZMA_STREAM_INIT.714*715* \return On success, the current memory usage limit is returned716* (always non-zero). On error, zero is returned.717*/718extern LZMA_API(uint64_t) lzma_memlimit_get(const lzma_stream *strm)719lzma_nothrow lzma_attr_pure;720721722/**723* \brief Set the memory usage limit724*725* This function is supported only when *strm has been initialized with726* a function that takes a memlimit argument.727*728* liblzma 5.2.3 and earlier has a bug where memlimit value of 0 causes729* this function to do nothing (leaving the limit unchanged) and still730* return LZMA_OK. Later versions treat 0 as if 1 had been specified (so731* lzma_memlimit_get() will return 1 even if you specify 0 here).732*733* liblzma 5.2.6 and earlier had a bug in single-threaded .xz decoder734* (lzma_stream_decoder()) which made it impossible to continue decoding735* after LZMA_MEMLIMIT_ERROR even if the limit was increased using736* lzma_memlimit_set(). Other decoders worked correctly.737*738* \return Possible lzma_ret values:739* - LZMA_OK: New memory usage limit successfully set.740* - LZMA_MEMLIMIT_ERROR: The new limit is too small.741* The limit was not changed.742* - LZMA_PROG_ERROR: Invalid arguments, e.g. *strm doesn't743* support memory usage limit.744*/745extern LZMA_API(lzma_ret) lzma_memlimit_set(746lzma_stream *strm, uint64_t memlimit) lzma_nothrow;747748749