luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-12-26 15:36:14 +01:00
Code Issues Packages Projects Releases Wiki Activity

docs: Stop claiming that gsize is wide enough to hold a pointer

Browse Source 
Standard C specifically does not guarantee this, and it's untrue on
CHERI architectures (which have 128-bit pointers into a 64-bit
address space, with the remaining bits used for a capability-like
mechanism).

Signed-off-by: Simon McVittie <smcv@collabora.com>
This commit is contained in:
Simon McVittie 2022-10-21 14:32:19 +01:00
parent 662661a8d0
commit 64945e6386
1 changed files with 13 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
glib/docs.c
View File

@ -515,13 +515,22 @@
/**
* gsize:
*
* An unsigned integer type of the result of the sizeof operator,
* corresponding to the size_t type defined in C99.
* This type is wide enough to hold the numeric value of a pointer,
* so it is usually 32 bit wide on a 32-bit platform and 64 bit wide
* An unsigned integer type of the result of the `sizeof` operator,
* corresponding to the `size_t` type defined in C99.
*
* It is usually 32 bit wide on a 32-bit platform and 64 bit wide
* on a 64-bit platform. Values of this type can range from 0 to
* %G_MAXSIZE.
*
* This type is wide enough to hold the size of the largest possible
* memory allocation, but is not guaranteed to be wide enough to hold
* the numeric value of a pointer: on platforms that use tagged pointers,
* such as [CHERI](https://cheri-cpu.org/), pointers can be numerically
* larger than the size of the address space.
* If the numeric value of a pointer needs to be stored in an integer
* without information loss, use the standard C types `intptr_t` or
* `uintptr_t`, or the similar GLib types #gintptr or #guintptr.
*
* To print or scan values of this type, use
* %G_GSIZE_MODIFIER and/or %G_GSIZE_FORMAT.
*/