User Tools

Site Tools


pdclib:drawingboard

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
pdclib:drawingboard [2020/03/09 07:14]
solar freopen() reimplemented
pdclib:drawingboard [2021/07/12 15:51] (current)
solar [Floating Point Support for printf]
Line 5: Line 5:
 Unfortunately, I have strayed a bit from that path, and ended up with more "action items" than I am comfortable with. That is why I opened this "drawing board", to write down my thoughts about all those "construction sites", getting them organized, and make the path onward a bit clearer. Unfortunately, I have strayed a bit from that path, and ended up with more "action items" than I am comfortable with. That is why I opened this "drawing board", to write down my thoughts about all those "construction sites", getting them organized, and make the path onward a bit clearer.
  
-===== Thread-local Storage =====+===== Threads =====
  
-With ''<threads.h>'' we get the ability to handle thread-local storage.+With later versions of glibc now finally supporting ''<threads.h>''we can expect to see software emerging making actual use of this header (instead of ''<pthread.h>''). However, when conducting some more involved tests with my implementation, I also found a couple of severe defects. (The ''thrd_exit()'' / ''thrd_join()'' return value handling is broken, for one.)
  
-One thing that is //supposed// to be thread-local is ''errno''. Since we already wrap access to ''errno'' through calls to ''_PDCLIB_errno_func()''that should not be all that difficultHowever it will require //initializing// things, and we don't get to call functions from ''_PDCLIB_stdinit.c''..+With ''<threads.h>'' we get the ability to handle thread-local storage. While I implemented a thread-local ''errno'' (which was simple enough), thread-local locale handling might turn out to be a bit more complicatedIt might require //initializing// things, and we don't get to call functions from ''_PDCLIB_stdinit.c''...
- +
-I also need to look into locale information, which IIRC is also thread-local (with the same initialization issue).+
  
 ===== Locales ===== ===== Locales =====
Line 23: Line 21:
 ===== time.h ===== ===== time.h =====
  
-Several time functions are not implemented yet. The ''gmtime'' / ''localtime'' / ''mktime'' group requires timezone information (which in turn requires me looking into the timezone database for proper support code). For ''asctime'' / ''ctime'' I need alternative access to the "C" strings in the //time// locale category, because they are both defined locale-independent.+I picked up the IANA reference implementation, tzcode, and am working toward an integration of that into PDCLib proper. This will do the time zone and leap second handling; it will also mean I will not have to maintain a separate database for time zone data. The Olsen database provided by IANA will do. 
 + 
 +At this point the code is made to compile correctly, and roughly tested. There is quite some refactoring to be done yet, before the tzcode feels "native" to PDCLib (which is my goal here, as opposed to dlmalloc which I //wanted// to stay as untouched as possible). 
 + 
 +For ''asctime'' / ''ctime'' I need alternative access to the "C" strings in the //time// locale category, because they are both defined locale-independent.
  
 ===== Floating Point Support for printf ===== ===== Floating Point Support for printf =====
Line 29: Line 31:
 A request from downstream was to add FP support to my ''printf()'' implementation (which currently **breaks** for %f/%g et al. because it doesn't draw the accompanying value from the stack -- not nice!). A request from downstream was to add FP support to my ''printf()'' implementation (which currently **breaks** for %f/%g et al. because it doesn't draw the accompanying value from the stack -- not nice!).
  
-I got a good introduction to the Dragon4 binary-to-string conversion algorithm as well as the paper for the Grisu3 small integer optimization, but this would be another major construction site (touching ''<math.h>'' and ''<fenv.h>'' matters as well), and I feel it would be just one thing too many to tackle at this point.+I got a good introduction to the Dragon4 binary-to-string conversion algorithm as well as the paper for the Grisu3 small integer optimization. Big Integer support is required for thereand already implemented, so there might be another checkmark added here soon (tm). 
 + 
 +Links: 
 + 
 +  * [[https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf|How to Print Floating-Point Numbers Accurately]] (Steele & White, //Dragon4//
 +  * [[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.72.4656|Printing Floating-Point Numbers Quickly and Accurately]] (Burger et al.)  
 +  * [[https://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf|Printing Floating-Point Numbers Quickly and Accurately with Integers]] (Florian Loitsch//Grisu3//
 + 
 +===== Annex K ===== 
 + 
 +Annex K of the 2011 version of the C standard defines a number of optional library expansions. These revolve around thread safety and buffer safety. They are generally thought to make a rather poor job of it (they very much carry Microsoft's handwriting). However, when I was asked to provide a reentrant version of `strtok`, I opted for providing the Annex K version (`strtok_s`) instead of opening the can of worms that is POSIX extensions (`strtok_r`). While the latter would admittedly have been the better solution, I simply did not want to go there, as I would have hung myself with a //partial// POSIX support forever. And `strtok_r` //can// be implemented in terms of `strotok_t`, providing an acceptable solution for the immediate demand. 
 + 
 +However, for now I am stuck with a //partial// Annex K support as well, which is a shame because there are mechanisms for the library to signal Annex K support to the application programmer, and right now this mechanism in PDCLib is lying, one way or another. I'd like to make the support complete, regardless of the poor design of the whole Annex K. 
 + 
 +===== Testing ===== 
 + 
 +There has been quite some ad-hocery going on with the test drivers lately. Coverage is not nearly as complete as I would like it. Many functions are without testdriver altogether, others (like the Annex K functions) have made exceptions for `REGTEST` because general library support was not available -- but they gloss over that quietly where they should probably report `NO_TESTDRIVER` or somesuch. I will have to go over all the tests once more to take out the slack.
pdclib/drawingboard.1583734442.txt.gz · Last modified: 2020/03/09 07:14 by solar