Bugfix: rules not properly handling status.

The status F_known_not was incorrectly being treated as busy.
Make sure to guarantee lock and then unlock of the process_other lock (read lock) to prevent execution of dependent rule while analyzing state of dependent rule.

Read the rule's status after executing from the rule in the rules array and not on the process.
The rules on the rules array is updated after execution but the process is not guaranteed this.
The status of process is generally reserved for the process to manage the status and not to represent the rule status.

Expanded the example serial execution test entries and rules.
Add a new alternative serial so that one uses normal execution and other uses dependent execution (execution is executed by something depending on it rather than being directly started via the entry).

Bugfix: nanoseconds should become seconds when a second is at least reached.

When adding to nanoseconds would result in a value greater than or equal to a second, instead increment by 1 second.

Progress: controller program.

I completely overlooked that the thread time related functions are relative to the absolute system clock.
The timed locks were all acting crazy because I used relative values!

The process status is not being initialized, resulting in invalid and error prone checks.

Begin fixing problems with the asynchronous processing.
Between incorrect uses of times and some stuctural problems, the asynchronous behavior was not operating in the order of the dependencies.
The current work fixes that, but there is still more work to do.
I expect this code to not work just yet.

There also seems to be a locking issue somewhere in here that prevents the program from fully exiting.
Check the thread conditions as those have had problems in the past.
.

Update: Finish implementing the thread condition functions.

It looks like the f_thread_condition_wait() f_thread_condition_wait_timed() functions were not fully written.
Add missing handlers.
The f_thread_condition_wait_timed() was even missing the return case of F_time!

Update the comments as the "time" value is relative to the absolute system clock time.

Add F_dead, F_live, and related.

Bugfix: improve cancellation point processing and handling.

This avoids the use of f_thread_cancel_test() which is horribly limited in design.
Because f_thread_cancel_test() never returns when thread is in cancelled state, the caller cannot properly handle the situation.
This limits the code design in order to properly use f_thread_cancel_test().

There are already cancellation points in place due to the extensive use of thread.enabled.
Improve these cancellation points, adding timed checks to write locks to further check if a cancellation was received (via thread.enabled).
The timeout is arbitrarily pick as "0.1 seconds".
Hopefully, this doesn't make things too busy, but really the write locks should (ideally) never have to be waiting that long anyway.

Remove stale code in private-common.c involving a write lock and then an immediate unlock on deallocation.

Add additional thread.enabled checks.

There were some places where cancellation points were being returned but were not properly unlocking all held locks that are within the scope of the function.

All threads should now be set to PTHREAD_CANCEL_DEFERRED.

The forced thread termination via kill signals are now removed.
They shouldn't be needed now that cancellation (should be) guaranteed.
This will have to be tested over time to confirm the truth of.

Update: handle POSIX compatibility automatically in f_thread_cancel_state_set().

The POSIX standard does not explicitly define that this parameter can be NULL.
To prevent any possible problems, allow NULL but when NULL is received, use a temporary variable in its place.

Bugfix: thread exiting issues and related.

My attempt to add locks to make helgrind ended up backfired on me.
It seems that when an interrupt is received, the cancel is being sent and it happens at any point in time.
Which includes when locks are opened.
When an interrupt cancels a thread with an open lock, that lock is never closed.
Then, using the same locks to handle cleanup of threads resulted in an occasional deadlock.
Remove all locking in the main thread.
The logic should be safe as the only cases where there might be a conflict, a f_thread_join() is in protected between them.
The cancel function should avoid locks to, where possible.
I am somewhat more nervous about this case, I need to review and confirm if main->thread->processs.size does not change.

I previously updated the force cancel exit thread to use waits and locks.
It later dawned on me that I could just get rid of the force cancel exit thread entirely and implement the same functionality in the cancel thread.

Update: redesign forced exit to utilize timed waits.

Update: lock handling tweaks.

Move the rule lock to inside the if condition block because part of the rule is still being read.

Add missing unlock for other process active lock before break.
Relocate the other process active lock in some cases to be after the last access to the rule.

Utilize process r/w locks around starting and joining the main threads.

On exit, check to see if id_exit thread is actually used before attempting to join it.

Progress: controller program.

Copy over the rule item action statuses when the rule process completes.

Update cleanup thread:
- deallocate rule data in no longer used space.
- make sure cache thread is being started.

Implement asynchronous example rules for testing.

Disable asynchronous execution when running in validation mode.
This ensures consistency and cleanliness when outputting the validation data.
There is no reason to run asynchronously in this mode because nothing is supposed to be run anyway.
Make sure that execution (simulated or not) is not performed in validation mode.
Make sure the program immediately executes at the end when in validation mode.

Workaround: weird print data when received by a pipe.

Not sure what is going on here, but it seems that the data is not correctly printing via pipes.
Add a flush before unlocking the print locks as workaround.

Cleanup: rename controller_rule_simulate() to controller_rule_validate().

This function is actually for the "validation" part of the simulation.
Changing the name makes it less confusing and more semantically accurate.

Progress: controller program.

Update some of the comments.

The "consider" was not being loaded into the "process" array.
Change the behavior to allow for loading the "consider" rules into the "process" array without executing them.

Fix a bug where some entry items were being skipped.
The counter was being added an extra time during the loop, resulting in the skip.

The child processes are not exiting cleanly.
The state F_child was not being fully bubbled up the call stack.

It seems that when forking within a thread, the forked child process, on exit will not result in the thread returning to the caller.
For now there is 1 block (according to valgrind) that is "possibly lost" for every forked child process.
A more in depth investigation is needed.

Add a stub for an asynchronous entry that I will be writing for additional testing of the asynchronous processing.

Cleanup: printing and stale code.

Structural problems related to printing.
Relocate how the final newline being printed on simulate is structured in the code.

Remove stale "simulate" variable that is no longer used.

Update: add pthread semaphore support and correct comments.

This includes named semaphores, using the words "semaphore_file".

Fix several problems with the comments.

Update: controller program should immediately exit when doone after validating.

When in validate mode, the controller progam should not sit and wait but instead should immediately exit.

Update: controller program should continue on error.

Except for certain error codes, like out of memory, record errors and continue onward.
Future versions should somehow handle out of memory issues if this program is to become an "init" replacement.

Avoid unnecessary assignment of rules error status.
In some cases, the rules error status was being assigned twice.

Update: add message when done processing entry.

Bugfix: wait condition issues, memory addressing issues, and exiting issues.

The thread conditions, when waiting, may never stop waiting.
Switch to a timed wait, allowing for the condition to determine if it should stop waiting.
I attempting to signal the waits on exit, but this didn't work (however, this will still signal on exit).

Make sure to join all threads, add a failsafe thread join in the process delete function.

The array of processes is a single array.
When this array gets reallocated (resizing to a larger size) the memory addresses may change.
This is a serious problem in that the threads are using those addresses and they suddenly change.
The threads have no way of switching to the new addresses and memory problems happen.
Redesign the array of processes to an array of pointers to processes.
I considered using a block structure, but decided to keep it simple for now.
The downside of this is that on every resize, there must be another allocation for the process address being pointed to.
In the future, I may consider switching to a block structure where I allocated multiple blocks at a time, while still using pointers.

Rename "id_process" to "id_child" to avoid potential confusion between "processes" and "pids", given that I am using "process" with a very different context in this project.

Update all timeouts to be stored in macros.

The cleanup and exit functions were deadlocking, change the locking usage in these functions.

Add missing increment at the end of the loop when processing entry items.

Bugfix: asynchronous processing is not working in controller program.

This is because I accidentally passed a pointer of a pointer instead of the pointer itself.

Progress: controller program.

Update: don't use WUNTRACED | WCONTINUED by default, provide "wait".

Don't have waitpid return if child stopped or continued.
Instead, provide a "wait" property to pass to waitpid().

Progrress: controller program.

This gets the program back into a semi-working state.
I've tested the threading and the previous threading problems appear to be gone.
That tells me this massive rewrite/redesign seems to have been worth it.

There is still a lot more to do:
1) Something is not being shutdown properly, on exit (using the control-c termination signal with -t passed to it).
2) The simulate parameters are no longer working (oops!).
3) The printing appears done, but I've confirmed some problems due to design*.
4) I have not done extensive tests, so there may be other regressions.

* As for the case of #3, the problem is with printf() (and fprintf()) and threading:
- The child processes will write to stdout and stderr.
- The controller program also writes to stdout and stderr.
- printf() and fprintf() guarantee locking, but this doesn't help between different executions.
- Writing one massive complete fprintf with, say 20 parameters, is ridiculous.

This leads me to believe the best solution is to write my own printf/fprintf replacement...which is a huge task.
If I do this, then I can get rid of all of that print locking and use the locking provided by the custom functions.
The difference being that these locks would be designated by another, special function, so that the locks can be held across function calls.
The other advantage would be being able to add support for many of the specialized FLL structures (particularly color printing).
The downside is I would need to do a lot of research in witing to the terminal (the putc() and similar stdio functions) and bufferring.
I would then have to handle all of this!
Which is a huge amount of work.
So, for the time being #3 will be ignored and left as a design flaw (or more accurately a design limitation).

Progress: controller program.

Progress: controller program.

Bugfix: fix thread initializers and add documentation on thread allocation requirements.

The PTHREAD_ONCE_INIT cannot be deleted.
The pthread_spinlock_t cannot use PTHREAD_MUTEX_INITIALIZER, so instead use ((pthread_spinlock_t) 0xFFFFFFFF).

Many of the thread structures require dynamic initialization.
Document this behavior.

Progress: controller program.

Progress: controller program and related.

Use "copy" instead of "clone", it seems more accurate given that the code is not guaranteeing the same exact memory structure (only the data is guaranteed).
I believe that I need to document my "completeness principle", documenting the structures and what needs to be done.
I also need to document the exception cases.

Implementing the rule copy function, I realized that I need to have the copy function and not just utilize the "append" functions.
There are many functions where "append" does not make sense.
This means that "copy" must be part of the completeness.

Comment out the cache clearing code.
I will probably get to that part last.

Cleanup: document _di_pthread_support_.

Provide simple "defines" documentation for "_di_pthread_support_", even though its technically not used in that project.

Bugfix: recently added capability functions are from newer version.

The libcap project hasn't been updated in a long time.
Apparently, somebody relatively recently picked up the project and started maintaining it.
This introduced newer functions.

For some reason, my system has a hybrid of this.
The headers show the newer functions but the libraries lack them.

Add a new define "_libcap_legacy_only_".
Enable this by default given how long libcap has exist unchanged.

I also noticed and inconsistency with the function names for users and groups (which are newer functions).
Rename them to not include the "_id".
Remove a duplicate function that didn't even have a reference in the header (oops!).

Update: capability.

Add missing typedefs and cleanup ordering of typedefs.

Add several more functions.
I found more functions than what are implemented now.
The problem is my current systems manpages don't easily find them (such as cap_new_launcher, cap_iab_init, cap_iab_get_vector, etc..).
I will not implement this for now and will need to do some research to see what they are.
Some functions are documented in the manpages as deprecated or obsolete.
I would rather not want to implement any of the deprecated or obsolete functions.

Make sure all "implemented not" functions still do parameter checking.

Use "clone" instead of "duplicate" to be more consistent with the terminology used in this project.

Add additional documentation.

Feature: support f_string_constant_t as a way to pass "const char *" as a parameter.

The parameter will have the return value and needs to be a pointer.
Passing "const char **", the "const" is applied to "char **", which is not what is wanted.
The desired logic is "(const char *) *", but that is not valid syntax.
To achieve this, "const char *" is turned into the typedef "f_string_constant_t".
This allows for "(const char *) *" to be used in the form of "f_string_constant_t *".

This is a special, exceptional, case and there are no plans to support an "array of" or any of the completeness practices.

Update: f_capability improvements and cleanups, and provide f_implemented_not status codes.

Provie F_implemented and F_implemented_not, then use them for capability function support.
This now replaces F_suppoted_not for this particular usage, allowing f_supported_not to be used more naturally for other purposes such as representing codes used by the POSIX libc standard.

Cleanup the documentation comments, updating to the latest style.

Add some missing capability functions (I think there are a lot more to do, so another commit will eventually follow this one).
A number of the status codes were incorrect and/or undocumented.
Make sure F_parameter is handled more consistent (adding it where it is missing).

My increased experience with the POSIX libc standard has led me to believe that it is not safe to use (XX < 0) comparisons when comparing for -1.
This is because POSIX libc is often more loosely defined so if it says -1, that allows for all other negative values to be implementation-specific.
By checking for (XX < 0), this would expose this project to potential implementation specific bugs.
This likely needs to be fixed everywhere, but for now f_capability is where I am starting.

A new function f_capability_supported_ambient() is provided to handle the CAP_AMBIENT_SUPPORTED() macro function.

Update: add documentation about return codes.

Progress: controller program.

Update: update utf string with string changes and fix problems with string.

Synchronize the utf string with the latest string changes.

I noticed that some of the disable macros are not used and should be for the private functions.

The *seek* functions needed to be fixed in string.
Add a missing *seek* function.

Update: add "eoa", add append functions, relocate f_string_dynamic*, and update comments,

"eoa" or "End of Array" is being experimentally added as a compliment of "eos" or "End of String".
Remove stale status code from before I fully embraced error and warning bits.

Add more append functions.
Make existing functions more consistent, checking for array overflows, returning F_array_too_large when appropriate.
Update the comments while I am at it.

Relocate the f_string_dynamic_* functions in string.h and string.c to string-dynamic.h and string-dynamic.c, respectively.
This requires that the string_dynamic.h header depend on string_range.h

Bugfix: should be using level 0 parameter checker macros in level 0.

Update: implement append functions for array types and implement all the other functions.

Start implementing all of the macros as real functions for these.
Macros do what I wanted and save writing code, but the binary size is more of a concern.
Switching to explicit functions should also make debugging easier.

The macros may be removed eventually and all of the code utilizing the macros will be updated to use these.

There will be more changes like this going forward in some other projects like f_string and f_utf_string.

Cleanup: use 'print' instead of 'error' for variable name.

Update: add done, empty, and full status codes.

Include the respective "not" codes as well.

Bugfix: more thread macros aren't correct.

Progress: controller program.

Continue working on the thread support.

There are considerable redesigns being implemented.
The code is currently in an inconsistent state.

Update: replace f_string_length_t (and related) and miscellaneous cleanus & fixes.

The f_string_length_t, f_string_lengths_t, etc.. types are somewhat redundant.
Simplify the code (reducing binary size as well) and just stick with the f_array_length_t types.

Miscellaneous documentation cleanups.

Progress: controller program, address issues with invalid reads/writes.

I have finally identified the cause of the confusing invalid reads/writes.
It seems that using the pointers to memory address directly associated with the thread data and then accessed within a fork() call is a problem.
By copying the data to variables local to a function and then using that memory address, the read/write problems go away.

This commit only performs an immediate fix for the current problem.
What I really need to do next is to rewrite/restructure much of the code with this behavior in consideration.
There were a lot of experimental changes I performed while trying to identify this problem.

There are still some additional locking and other thread problems to solve.
These will hopefully be fixed by the planned rewrite cleanup that I need to do.

Progress: controller program.

Continue working on the thread support.
As I am learning how to use threading, I am finding that my conversion is flawed in some way and somehow losing the pointer address.
I worry that this might be related to how realloc() changes the pointer address, but there is no strong evidence to this fear.

I've decided to just save the current state (regardless of its state) and will rethink the design.
Currently the behavior is more consistent but still problematic.

Update: memory function tweaks, update thread code, and improve execute functions.

Restructure the memory functions a little.
Add comments about realloc() potentially changing the pointer address.

A few of the thread type macros are missing semicolons.
Remove f_macro_thread_mutex_t_clear().
There are likely other thread types that cannot be set to 0, and they will be correct as I discover them.

Rename the thread condition block and unblock functions.
Add missing f_thread_detach() implementation.

The execute fnctio fll_execute_program() should use pid_t when returning a PID.
This is potentially different from int, so instead use a void * and cast to an int * or pid_t * as necessary.

Cleanup: don't re-use 'result' variable name, and fix documentation.

Update: remaining thread functions and add f_recover (and f_recover_not) status codes.

Implement the remaining POSIX thread functions that I am aware of.
I took a break in the middle of writing some of this so I expect there may be some mistakes resulting from such an interrupt.
I do not feel like focusing on this now and will address any problems as I discover them.

Progress: controller program and f_thread.

Add more mutex lock protections.
The thread->data->child is shared and cannot be used as a per thread child process storage, so comment out and add an @fixme.

In the case where the exec() functions return in the child process, the mutexes may not be fully trusted.
All the child process should do is find its way to the exit, deallocating along the way.
Avoid all mutex-related and printf() related functionality where possible.
There were some places where the F_child is not being checked for and returned on but should be checked for and rreturned on.

Work towards improving the mutex locking logic when working with the asynchronous processes, caching, and cancelling.
There is more work to do in this regard.

Sleep interval for the cache cleanup thread now uses the short timer when in test mode and the long timer in non-test mode.

Add a list of functions that need to be completed for t_thread.
Add f_thread_mutex_attribute_t and f_thread_mutex_attributes_t related functions.
Minor cleanups in f_thread.

Progress: controller program and related.

Add f_signal_send().
Cleanup some of the f_signal code.

Add "return" mode option to fl_execute.

This adds more thread related changes, much if this I am semi-experimenting.
I will likely do a post review and try to clean it up and remove anything unnecessary.

One thing in particular that I am trying is saving the child process PID for a foreground process.
This can then be manually sent a termination signal on exit.

The program should exit in certain validation modes.

Cleanup f_environment logic in one function.

Update: add missing thread functionality and fix an initializer.

Progress: controller program.

Wrap all print functions that print while any threading is in used with a mutex lock.

Add controller_execute_set_t to shorten the execute function arguments.

Add missing f_gcc_attribute_visibility_internal.

The controller_rule_read() inside of entry does not need to be read locked.
This operation happens before any threads are started.

Replace simulate argument with options argument for execute functions.

Add more verbose output in the simulation for the execute operations.

Cleanup: macro functions should have 'macro' in their name.

Bugfix: thread delete functions and related.

Bugfix: incorrect data type being used.

This should be f_array_length_t and not f_string_length_t, for array lengths.
There are some cases where the string length is using f_array_length_t, which ironically should be f_string_length_t.

Progress: controller program thread support.

This is the initial pass at getting the thread support implemented.
There were several necessary changes in how the cache is defined and used.

This is very much incomplete.
All of the printf functions after a certain point need to be protected by a print mutex.

I need to figure out if and how to handle child processes from an execv() call from inside a thread.
Ideally it needs to gracefully exit and cleanup resources in the child process.

Just like with the child process and execv() the signal/interrupt handling needs to be handled in a way that gracefully exits as appropriate.
Prior to adding thread support, I added signal support and tested that it works.
These interrupt signals work but have not been tested or reviewed now that the threading is added.

A quick execution of this code shows that there are invalid reads (and therefore segfaults).
I need to pick up here and make sure all of the resources are being properly managed.

Bugfix: missing semicolon, missing macros, add todo, and remove extra errno check.

Add a missing semicolon.

Add the delete macros that are missing.
After looking at this, I noticed that I will need to call these delete macos, so add a @todo to designate that a series of memory management functions need to be written for this.

The ETIMEDOUT is not valid fo the f_thread_create() function.

Cleanup: comment for memory function.

Update: f_thread_create() fixes.

The f_thread_create() function should allow for attribute and argument to be optional.
The pthread_create() allows for attribute to be NULL and I am now also assuming that the passed arguments can also be NULL.

Update: add missing property to control program data structure.

Update: synchronize f_utf (and fl_utf) with f_string (and fl_string), update f_string and fl_string, and fix some bugs.

Get the UTF related code more up to date and in sync with all of the string changes.
This brings the UTF string types in line with the normal string types.

Much of the code is moved out of fl_utf and fl_string and into f_utf and f_string.

This is only the first pass at updating the UTF code.
The function comments need a cleanup pass.
The pre-existing incomplete UTF code remains incomplete.

There were some minor bugs and typos that needed fixing that I happened across while working on this.

The UTF string types should just use the same length types as the string types.

Rename the *_non_graph() functions to *_graph_non().

There will need to be another follow up commit to cleanup the code that as of this commit now contains duplicate code.
The FSS processing code is a likely case for this.

Update: fix regressions due to recent mass structural changes and apply some updates.

Fix typo in documentation 'object' should be 'name'.

Remove *_quote_delete() and *_quote_destroy() functions.

When I fixed the logic in some of the macros and the recently added functions, I failed to do so for some of the memory structure functions.
This caused failures during the Featureless Make "make" compilation.

I decided to go ahead and expand the macros, which was necessary for exposing the bug but I decided to keep them expanded.
These are private functions and the macros are there for helpers not so much as a rule.
The expansions directly call the f_memory_delete() and f_memory_destroy() functions (good thing I decided to keep those!).

In some cases, use *_increase() functions where possible.

Get rid of moe of the old FSS private functions that are now functional duplicates of functionality now provided by the f_type_aray, f_string, and f_memory.
This will be an ongoing thing.

Remove stale comments referencing "f_memory_out".

A bug was discovered (not a regression) where I used incorrect logic and was acting on potentially unallocated memory when passing the contents_quoted to another function.
Call the appropriate *_increase() function before getting the memory address to a content quote.
This bug is also causing problems with the Featureless Make "make" process.

Bugfix: regression in how an optional variable is handled.

Cleanup: update f_memory function structure to follow more recent practices.

The more recent practices being followed are having constants on the left and pointers on the right.

The f_memory functions appear to be well followed and the update to this turned out pretty easy.
Despite how many things depend on memory operations in this project, there is actually very little to change.
I consider this a small victory in how my project is designed and intended to be used.

Bugfix: recent changes in macro structures broke iki_read.

Bugfix: f_type_array has different headers.

Update: more FLL cleanup and consistency.

Finish the previous cleanup and consistency changes.
There is likely more to do, but I believe this is enough for now, at least in regards to this set of changes.
Much of the code is refreshed in terms the memory structure.

I don't like doing this but after some consideration, I have decided to break out the array types from f_type into a new project, f_type_array.
This is an exception cases of the exception cases (unfortunately).
This acts as an extension to f_type, except that it depends on f_memory.
This will provide common functions for array types.
Parts of this remain defined in f_type because f_memory also depends on these arrays.
By handling code this way I can avoid circular dependencies in both f_type and f_memory.

One major change is now that I am implementing more functions in place of the memory-related macros (to save space, overall), I find it easier and simpler to only use resize and adjust in place of delete and destroy.
This significantly reduces the amount of code needed in regards to trying to achieve completeness.
I was also considering removing f_memory_delete() and f_memory_destroy(), but decided to roll that back.
The f_memory_delete() and f_memory_destroy() are low level and should still exist for completeness even if I am re-using adjust and resize for many of the other parts.
For example, there are cases where I may need to call free() on types not defined by this project, these functions will be helpful.
Furthermore, to help hackers implement their own variations of things, providing these may be a boon.

This is such a massive change that I am concerned of regressions.
I have done some quick compile and run tests using the programs so I believe that this is reasonably done without regressions.

I plan on doing a refresh the UTF-8 string processing code (which will be a complete refresh to be just like the recent f_string changes).
There may be other changes needed to prep the state of the code before I do this.

Progess: FLL cleanup and consistency.

Bugfix: f_fss_set_quotes_t incorrectly has f_fss_set_t instead of f_fss_set_quote_t.

Update: Remove *_decrease() and *_decimate() macros and functions.

My general design goal is "completeness".
I originally looked at the *_decrease() or *_decimate() macros and functions as a completeness compliment of the increase() macros and functions.

There *incease_by() macros and functions as well as their compliments can already resize by 1 (or any given amount).
This means that the *_increase() (and similar) are not needed.
This puts the *_increase() in the position of an "exception" case.
As an exception case, I believe it does not necessarily need a completeness compliment.

Unlike the *_increase_by() macros and functions, the *_increase() increases by 1 or more (depending on the definition of the macro f_memory_default_allocation_step).
There is no logical compliment of this behavior for a decrease() macro/function.

Therefore, I believe it is more appropriate to remove all *_decrease() and *_decimate() macros and functions.

Update: collapse projects using fl_string as necessary and replace dependencies as necessary.

Progress: restructure string project and eventially utf project.

This collapses much of the code from fl_string into f_string.
I have originally wanted to keep f_string source file free to help reduce recursion but the design kept leading me to deciding to do this.
The final straw was the extern const strings.

This moves all of the string related functionality that does not strictly depend on f_utf into f_string.
I expect that the fl_utf and fl_string will be merged together into fl_string.
I also expect that following these changes and the related cleanups then I will be at a good point to update and get the UTF-8 processing code in sync with the current string processing code.
That is, the f_utf_string needs to work similar to f_string types as well as have the same functions.

This collapsing of the level 1 code into level 0 code will also require an update on all appropriate dependencies (header files being included, etc..).

I also strived for more completeness in this and added many missing functions and macros.
I did not get as far as I would like, resulting in this being a Progress commit instead of an Update commit.

Update: consistency issues in code design, better utilize global constants, and other related changes or cleanups.

Over time the code gets out of sync and less consistent.
Update the source code structure to be a bit more consisten.
There are more commits like this to come.

Some of the consistency improvements involve:
- Utilizing the XXX-common.h (and now XXX-common.c) sources.
- Utilize the private-XXX.h and private-XXX.c sources.
- More consistent declaration of allocation-related macros.
  - This updates mostly the array related structures.
  - This does not include the matrix related structures (an array of an array) to keep this commit from being too massive.
  - Re-order how I declae the allocation macros.
  - Add more of the increase(..), decrease(..) and similar macros (there will be further work on this in the future).
  - Use keyword "register" for the resize, delete, and similar macros.
- If there are any sources, the main source for a project will exist even if it is empty.
- Start a practice of using "_s", even in the define declarations for the "_di_XXX_" blocks.
- Add semicolons at the end of macro functions.
  - In the past, I decided to not have these but now I have decided the semicolons probably should be there as a practice (even if their presence could be redundant).
  - Any exception cases where a macro function is meant to be used inline will not have semicolon.
  - I only spent so much time on this an there are likely several more macros to cleanup in this regard.

I have been using "const static" for global strings.
I seem to have forgotten that the C keyword "static" does not operate like "static" would natural do so in the global scope.
The solution is to remove the static and make these "extern".
Then those "extern" must be added to a source file and compiled in.
Use these newly defined global constants strings more consistently.

This adds a source file to f_string project.
I tried avoiding this in the past but now that I am, I should move much of the fl_string code into f_string.
This will simplify the project in many ways, but the changeset will be huge.
To avoid mixing too much more in this commit, I will address this aspect at a later date.

Simplify the allocation error, reducing memory related statuc codes to just F_memory and F_memory_not.

The recent changes where thread (pthread) support being added caused problems (and revealed problems) in my package helper script.
Fix the revealed problems in the package helper script.
Update the package helper script to better handle the special situations in regards to thread support.

Update all of these settings files based on the dependency changes and the packager helper script changes.

Fix a bug in the memory resize/adjust logic where I failed to consistenty memset newly allocated space.
This is the result of checking to see if the pointe has changed.
I no longer no why I was doing that and it seems plainly wrong.
I also never consistently performed memset() after calloc() (Inside the adjust/resize, memset() is not being called).
Newly allocated memory should be guaranteed zeroed according to the designs of this project and this should now be true.

Minor cleanup in the filesystem paths.
I renamed "filesystem" to "tree" in this regard and relocated that code to the path-common.h, dropping the path_filesystem.h file.

Add ascii characters.
If I am going to use hardcoded strings, use the global constant strings to reduce the code size (even if only by small margins).
More work is needed here, I only did what I needed to do.
I would note that this is intended for ASCII only and is not intended to be locale/language aware.

Any error message during testing lead me to noticing a problem in the private_fll_error_print() in regards to the text being printed.
Add the access denied error message while I am at it.

Bugfix: conversion scale maximums are too short and rename scale to digits.

The "scale" max is not consistently correct.
In some cases I have the signed one number less than the unsigned version (which should only be true for the binary representation).
In other cases, I should have a larger number because it doesn't fully represent all digits.
This is likely a mistake resulting from my misuse of the term "scale".

The way I am using "scale" is not exactly correct with the meaning of the word.
Rename "scale" to "digits" to better represent what this variable its related defines are for.

Update: memory changes, macro changes, and return type changes.

The practice of having an increase(), increase_by(), etc.. has become standard.
Redesign the code to better follow this, simplifying the code base some.
There is more work to do in this regard, but this focuses on just changing the existing code.

While I prefer to always return "const" where I can, simplify the design to always return "f_status_t" instead of using the wrapping macro "f_return_status".
This will make things between C and C++ more consistent.

Cleanup: fix typo.

Cleanup: use the structure macros for memory operations.

How silly of me.
I have these structure macros and I am not even using them in this class.
Fix the f_thread project to use these structure macros.

Progress: controller program and other minor tweaks.

Add support for "affinity" and "limit" to the controller program (and the execute functions from the execute projects).

The "affinity" allows settings specific CPUs to run the process on.

The "limit" allows for customizing the resource limits (ie: ulimit) in the process.
The resource names are used as-is, such as defined in /etc/security/limits.conf on some Linux systems.
Only the well known resource types are supported.
(For example, debian systems has 'chroot', which is not supported by this implementation at this time.)

New projects are added to address these features.
A project f_schedule is suggested by the comments added in this commit and may be introduced on a later date.

Minor tweaks includes using a global static variable for the space as a string " ".

Cleanup: remove redundant memset() calls.

The f_memory_*() functions already call memset() where appropriate.

Update: thread support.

Finish wrapping the pthread functions using f_thread.

I have observed some problems under GLIBC where static linking and -pthreads do not appear to work.
This is a problem with GLIBC as far as I can tell and I must ignore it to the extend that I can.
That said, because of the problems I decided to disable static compiling by default.

Either a better libc should be used or the static libraries should be compiled with thread support disabled.
I have not yet decided whether or not I intend to have thread suppot enabled or disabled by default.
The current default as of this commit is enabled.

There are some tweaks to the build settings to make things slightly easier when building with threads disabled vs threads enabled.

Completely separate f_signal from f_thread (where previously f_signal has conditional thread support).

Add a threadsafe option to fl_execute_parameter_t to conditionally use a threadsafe signal handler or not.

Cleanup: provide empty static strings and use the static strings more often.

Feature: add F_time and F_time_not.

Update: fix length calculation (cannot be 0), add f_memory_new_aligned(), and other changes.

The length calculation is documented to not be allowed to be 0.
Make sure the parameter checkers assure this behavior.

Provide f_memory_new_aligned() as a wrapper to posix_memalign().

The calloc() function actually accepts the length arguments as the first parameter.

Remove memory times and just stick with size_t.

Cleanup: use correct parameter checking levels.

There are some cases where the code is using the wrong level define when wrapping parameter checking.

Update: next micro version (0.5.3).

Progress: begin writing thread support and fix a problem in fss_extended_read project.

This is an end of the year progress commit (at least end of the year in my timezone).

The thread functionality is only barely implemented and one should expect a lot of future changes.

Progress: controller program, restructure some of f*_execute functionality, and add or update documentation.

For the controller program:
- add "freeze", "thaw", "pause", and "resume".
- improve simulation to actually perform an execute, but with a stub execution (an empty bash script).
- print more information when performing the stubbed simulation.
- simulation should not stop on errors when simulating, there are a number of cases where stopping is still happening.
- add a microsleep during the stubbed execution to better simulate synchronous vs asynchronous behavior.
- The F_schedule is no longer being returned from the child process, do not treat it as a child exit state.
- add more documentation.

Progress: control program, adding numerous FLL projects as needed.

This focuses primarily on getting control groups working.
There are also some f_account changes, but nothing in the control program used the f_account changes.

Progress: scheduler support in contol program.

The control (aka cgroups) will be implemented in an isolated commit as I suspect the required changes will be more extensive.

Progress: controller program and other changes.

Lots of changes with the most notable described below.

This adds support for capabilities, which depends on the external libcap (-lcap).
This introduces a problem because it is POSIX complaint in the sense of a draft and Linux has adopted it.
The end result is that instead of being in libc, the functions are defined in libcap.
To address this complication, a new project f_capability, is added to conditional compile in support and otherwise provide stubs.
This allows the rest of the projects to just call the f_capability functions without needing as many macros.
A define macro is still needed and the appropriate libary (-lcap) is still needed (or not if disabled).

I have further observed that when adding -lcap, the ar progam's ficklness on the order becomes a problem.
As a temporary work around, I am appending the "build_libraries" after all libaries introduced by a mode.

Progress: controller program and execute "as" additions.

The execute "as" additions are very much incomplete as of this commit.

Progress: controller program and execute function improvements.

Get rid f fl_execute_parameter_option_fixated.
A better approach is just to allow a 0 to be passed instead of the string (aka: NULL).
The execute functions can then detect whether or not full fixation is needed.
An additional parameter check is now needed as if the program is 0 then there must be at least 1 argument defined.

Due to design changes the 'method' property for individual rule actions no longer needs to be on the rule action structure.
In fact, it is now confusing as each action represents only a single action (itself).

Add support for the "script" rule setting to designate the script program to run for scripts.

Add additional example entries and rules.

Security: free the memory of the environment variables map.

Immediately after pushing my previous commit I suddenly noticed that I forgot to delete the newly added environment variables map.

Progress: controller program and related changes, such a adding fll_environment.

The environment loading functionality is likely to be very common.
Create fll_environment (because it depends on fl_string) and provide the environment variable loading functionality.
Replace the related code from Featureless Make to use the code from fll_environment.

Instead of using two string arrays, use an array of string maps for the environment.
Make the appropriate changes in all affected projects.

Add the fll_execute_as() function to perform an execution without a fork() operation.
This will become important once I write the f_asynchronous and related projects.

A new execute parameter option fl_execute_parameter_option_fixated is introduced to allow for execution without automatically prepending the program name at index 0.
There are existing projects that have to reconstruct an array to meet the structure of the execute functions (which then reconstructs the array again...essentially back to how it started).
This is a bit ridiculous and an artifact of the previous design.
With this new execute parameter option, the array is not reconstructed and assumed to be correct.

The controller program now sets the environment variables on the executed process (which currently only script execution is written).

Update: rewrite the execute functions to accept a parameter structure.

This changes the programs so that the execute function that handles piping data to the child in a separate function to normal execute function.
This happens via a private function and is therefore transparent to the caller.

The caller can select options to pass to tweak the operation of the execute function.
While I do not like using structures in this way as it complicate the code in one respect, in another respect it simplifies things.
There are also fewer parameters passed which is easier on the registers.

The f_execute_asynchronous_t structure is not needed with this design.
Future changes will include a new project (likely called f_asynchronous) to assist in performing asynchronous tasks.

Note: this go around I am trying constant pointers.
This makes it compatible when passing constants through.

Progress: controller program, working on execute script logic.

I have been tossing around how exactly I want to implement the execute with piped data.
I have decided that I should clean up the parameters and redesign it to accept a few specialized structures.

Before I do that, I wanted to confirm that the pipe to shell (such as bash) works as I expect it to.
This tweaks the code to a temporary state where I can automatically execute some bash script with some string piped to it.
This seems to work as expected and errors out as expected.

I also need to write some asynchronous functions to help with managing asynchronous processes.
This might require a new series of projects (f_asynchronous, fl_asynchronous, etc..).

Note: "bash" was used as the default script, but I really need to provide some sort of configuration to change this.

Progress: controller program, featureless make tweaks, and execute cleanup.

I am going to be using controller program to codestorm how I want the execute functions to handle forking with child.
I may simplify the "pipe" arguments to only accept an input pipe and then write a execute fork functions that perform the fork and return to the caller so that the caller fully handles everything.
This would allow for the "non-fork" (as in "fork" is not in the function names) functions to only focus on simple executions.
This could then make way for the asynchronous behavior that is planned.

Progress: controller program.

Feature: add F_optional, F_optional_not, F_require, and F_require_not.