Plan 9 from Bell Labs’s /usr/web/sources/contrib/quanstro/types

Copyright © 2021 Plan 9 Foundation.
Distributed under the MIT License.
Download the Plan 9 distribution.

types \- c type system
.BR char , 
.BR short ,
.BR int , 
.BR vlong
.BR uchar ,
.BR ushort ,
.BR uint ,
.BR uvlong
.BR u8int ,
.BR u16int ,
.BR u32int ,
.BR u64int
.B Rune
.BR usize ,
.BR uintptr
.B uintmem
.B schar
The Plan 9 C compilers and system use a specialization of the C99 type system,
which has evolved over time.
The compilers are unsigned preserving, and
.B char
can generally be assumed to be a signed value.
Although the system currently makes heavy use of
.BR ulong 
to represent exactly-32-bit integers and pointers as unsigned
integers, this practice is no longer supportable with the advent of
true 64-bit compilers.  Having a more explicit type set permits us to
be more specific about intent and is helpful to maintain portability
to other systems, especially Plan 9 from User Space.
The basic 8, 16, 32 and 64-bit types are
.BR char ,
.BR short ,
.BR int ,
.BR vlong.
Conventionally, unsigned types simply prepend a "u" to the basic type name rather
than using the
.B unsigned
Most programs will need no more integer types than this.  Exceptions
come in two forms: the need to be specific about use to aid in
porting, and type widths fixed by hardware or protcols.
The system call interface does not fit the second case since the compiler
itself will pick the same sizes for both kernel and user space.
To specify an integer of a particular width, the form
.BI u bits int
is used.  Types for 8, 16, 32, and 64 bit-width specific unsigned
integers are available.  There are no signed variants of these as they
are not useful where size-specific types are appropriate.  As a
special case,
.B uchar
is assumed to be equivalent to
.BR u8int .
Beware of using size-specific integers in a structure as a marshalling
technique.  The compiler is free to pad the structure and endian
conversion can easily be forgotten.  Consider using a structure
of basic types (typically uchar) marshalled with functions as in
.IR getbe (2).
.B Rune
type stands alone.  It holds a single unicode codepoint as
described in
.IR rune (2)
.IR utf (6).
The use-specific types are
.B usize
.BR uintptr .
.B Usize
represents the type returned by the C
.B sizeof
operator.  It is typically the same width as a virtual address.
In order to ease the transition to 64-bits, the AMD64 compiler
currently uses a 32-bit
.BR usize .
An integer representation of a virtual-address pointer is represented by the type
.BR uintptr .
The kernel additionally needs to specify a type to represent a
physical address. Since physical addresses may be the same size,
larger (PAE) or smaller than virtual addresses,
.B uintptr
as a physical address may be the same size, larger (PAE), or smaller than a virtual address.
.B Uintmem
also stores the sizes of things that
.B uintmem
might address.
.B schar
is used when porting to other systems where it may matter.  It should not generally be used.
The C library has a number of functions which are in need
of conversion.  For example,
void*	malloc(usize nbytes);
int		segfree(void *va, usize len);
uintptr	getcallerpc(void*);
A device driver might access a 32-bit register with
u32int regval;

regval = regbase[regoff/4];
In the kernel we could convert between physical and virtual addresses
this way:
uintmem	upaddr(uintptr kva);
uintptr	upaddr(uintmem pa);
The actual functions use
.B void*
for kernel addresses.
.IR 8c (1),
.IR getbe (2),
.IR rune (2),
.IR utf (6),
Plan 9 from User Space,
The spirit of the original type system has faded with time.

Bell Labs OSI certified Powered by Plan 9

(Return to Plan 9 Home Page)

Copyright © 2021 Plan 9 Foundation. All Rights Reserved.
Comments to