libk  Diff

Differences From Artifact [d664110812]:

To Artifact [28cd81b166]:


     1      1   # kcore
     2         -**kcore** is the foundation for the rest of libk. it defines types and structs that are needed by every program, and provides the stub that launches a program's "entry" function.
            2  +**kcore** is the foundation for the rest of libk. it defines types and structs that are needed by every program, and provides the stub that launches a program's "entry" function. unlike the non-core modules, kcore definitions simply use the prefix `k-`.
     3      3   
     4      4   ## entry
     5      5   when using libk, your program's entry point will not be the `int main(int,char**)` function that libc opens into. libk will call the function `stat entry(kenv)` instead. like libc, the value returned by `entry` will be returned to the host platform.
     6      6   
     7      7   ## types
     8      8   kcore contains fixed-width integer types (in <k/type.h>). note that the availability of each depends on your platform; compilation will fail if e.g. you try to use a u64 or a u128 on a 32-bit platform, so where exact lengths are not required, you may wish to use the built-in C types instead.
     9      9   
................................................................................
    28     28    * `kvar* vars` - a pointer into the program's environment
    29     29   
    30     30   ### struct kvar
    31     31   `kvar` is a struct that abstracts over platform environment variables.
    32     32    * `kstr name` - the name of an environment variable
    33     33    * `kstr val` - the value of an environment variable
    34     34    * `char* platform` - a pointer into the platform's underlying representation
           35  +
           36  +## functions
           37  +
           38  +### kstop()
           39  +
           40  +`noreturn void kstop(stat)` terminates the program immediately, returning the specified integer to the OS as an exit status. the type of integer it takes depends on your operating system. consider using the `enum kbad` defines in `<k/magic.h>`, which are designed to standardize exit statuses across different software and are synchronized with a FreeBSD effort to do the same (`<sysexit.h`).
           41  +
           42  +## definitions
           43  +
           44  +kcore is the only module that defines any terms outside the k- namespace. the only terms it so defines are native C terms like `noreturn`, which are implemented as keywords in a reserved namespace (`_` followed by an uppercase letter; in this case, `_Noreturn`). macros are then defined in new headers for the "natural" version of the term in order to avoid breaking older code. examples of this technique are `<stdbool.h>` and `<stdnoreturn.h>`. since libk is designed for new, modern code, breaking old code isn't a concern, and we turn on all these new keywords as soon as you load `<k/core.h>`.
           45  +
           46  +libk attempts to find the best possible definition and implementation for these various types and keywords, abstracting across different C versions and dialects. you can go ahead and use the normal version of the keywords (e.g. `noreturn`, `bool`) no matter what kind of compiler you're using and you're guaranteed that as long as you don't go fiddling with undefined- or implementation behavior, your code will behave the same every time. at worst, it may lack a few optimizations or warnings.
           47  +
           48  +(the one minor exception is `null`, a new keyword which libk uses in preference to the ugly, hard-to-type C macro `NULL`.)
           49  +
           50  +`bool` is implemented as a `_Bool` typedef if `_Bool` is available, and as an enum typedef otherwise. either way, and regardless of whether `KFclean` has been defined, booleans can be used and set to the values `true`, `false`, `yes`, or `no`. `yes` and `true` are synonyms, as are `false` and `no`.
           51  +
           52  +### macros
           53  +
           54  +if the flag `KFclean` has not been defined, kcore defines a number of macros to abstract over nonstandard C features. for instance, the `KA*` macros can be used to specify GNU/clang attributes without worrying about compatibility, as they'll automatically be blanked under an incompatible compiler. the KA series includes:
           55  +
           56  +	* `KApure` - marks a "pure" function that changes no state and only takes purely numeric arguments, allowing the compiler to avoid repetetive calls to it or even evaluate it at runtime.
           57  +	* `KAnoreturn` - the GNU/clang-specific version of `noreturn`.
           58  +	* `KAunused` - acknowledges that a variable is unused and tells the compiler to shut up about it.
           59  +	* `KAinline` - forces the compiler to inline a function whether it likes it or not.
           60  +	* `KAflatten` - placed on a function, will force-inline all function calls *made by* that function — sort of like `KAinline` in reverse.
           61  +	* `KAformat()` - specifies that the function has printf-style syntax for error-checking purposes. worst hack in history.
           62  +
           63  +if you wish to add more (there are like, hundreds) please consider making a merge request. however, the generic macro KA() is also available in the interim: `KA(unused)`.
           64  +
           65  +however, unlike C++ attributes, GNU-style attributes can only be placed on a function declaration, *not* its definition.