Rick, I think you are better off posting your code without any HTML formatting. I had to copy/paste from the browser to a text file; that is where the struggle with formatting comes in. I recommend using Github for this sort of thing, or just post the plain text source with a link to it. > > C unions have counterparts in Pascal variant records. All the "feature > test macros" used (see getconf) in the C library work for a C compiler > and not Pascal. So C++ really seems best. Freepascal has a utility > "h2pas" that helps convert headers to pascal. But I'm actually satisfied > with the posix timer results. The "siginfo" signal handlers are > non-essential. > Unions as a C standard are very specific. But I think the compiler will align those objects with the memory given the underlying handling by the hardware. I suspect, but do not know, that whether it is a Pascal or a C compiler, etc, the outcome should be the same. Sounds like that utility to convert headers will be enlighting to any non-Pascal coders like me. I will have a look; I have not had the time. Let's take a step back. You wanted high-resolution timers so that you can run events in a GUI for the purpose of graphing things in a window, etc. I had said that you do not need that kind of resolution for timing screen events, and that it is self-defeating (in my opinion) given that the X has to inerpret, handle and draw, which will take an arbitrary about of time. You can achieve the same by checking the clock (gettimeofday() for example) and re-checking post event to trigger a redraw. This is standard practice in gaming, etc. What happened since and what did you end up using? This discussion sort of derailed a bit. > I'm now playing with old Unix domain sockets software, and as usual, > Linux has some new treats. Linux recently added SOCK_SEQPACKET types. > What relates to this discussion is how some programmers are advocating > pre-pending a message with a size byte to define message blocks. But > that is exactly what freepascal does for old strings types. The null > "terminated" C strings are a hazard. > The null-terminated strings is yet another convention, if you like. They are just arrays of characters, and they are "strings" if *by convention) are terminated by a null character. When you assign a pointer to a constant "string" the quote at the end (which is considered a pointer in programming, I think) is where the null character is automatically placed by the compiler. If you turn on all GCC warnings you can do: char *s = "some text\n'); and get a warning that you have a redundant \n (null char) at the end. The standard of the language or the construction of the compiler can differ a bit for languages like Pascal, Fortran, etc. In fortran, for example, all functions that accepted strings actually accepted pointers to strings, and additional arguments were placed at the end of the function's nominal arguments that indicated the size of the string that was passed. I cannot say I like this, but it was completely covered under the hood for anyone who did not mix fortran with anything else. Your mention of domain sockets reminded me of a joke, with which I wish to end yet another pedantic post: "The good thing about UDP jokes is that I do not care whether you get them or not."