Top |
ArvZip * | arv_zip_new () |
void | arv_zip_free () |
void * | arv_zip_get_file () |
const GSList * | arv_zip_get_file_list () |
const char * | arv_zip_file_get_name () |
size_t | arv_zip_file_get_uncompressed_size () |
#define | ARV_GUINT16_FROM_LE_PTR() |
#define | ARV_GUINT32_FROM_LE_PTR() |
guint16 | arv_guint16_from_unaligned_le_ptr () |
guint32 | arv_guint32_from_unaligned_le_ptr () |
size_t
arv_zip_file_get_uncompressed_size (ArvZipFile *zip_file
);
#define ARV_GUINT16_FROM_LE_PTR(ptr,offset) arv_guint16_from_unaligned_le_ptr (ptr, offset)
#define ARV_GUINT32_FROM_LE_PTR(ptr,offset) arv_guint32_from_unaligned_le_ptr (ptr, offset)
guint16 arv_guint16_from_unaligned_le_ptr (const char *ptr
,gint16 offset
);
See arv_guint32_from_unaligned_le_ptr
.
guint32 arv_guint32_from_unaligned_le_ptr (const char *ptr
,gint32 offset
);
Here's an excerpt of the ARM documentation:
"Unaligned data access in C and C++ code
It can be necessary to access unaligned data in memory, for example, when porting legacy code from a CISC architecture where instructions are available to directly access unaligned data in memory.
On ARMv4 and ARMv5 architectures, and on the ARMv6 architecture depending on how it is configured, care is required when accessing unaligned data in memory, to avoid unexpected results. For example, when a conventional pointer is used to read a word in C or C++ source code, the ARM compiler generates assembly language code that reads the word using an LDR instruction. This works as expected when the address is a multiple of four, for example if it lies on a word boundary. However, if the address is not a multiple of four, the LDR instruction returns a rotated result rather than performing a true unaligned word load. Generally, this rotation is not what the programmer expects.
On ARMv6 and later architectures, unaligned access is fully supported."