Last week there was a gag listicle making the rounds entitled (Continued…)
an occasional series of items
too large to be throwaway
too small to be projects
unlikely to be revised
If you get this error message, the Internets may lead you to believe that you have no option but to change magic numbers in the source code and recompile
flex. Reader, it is not so. Try the
-Ca option, before doing anything else.
No, I don’t know why an option that’s documented to be all about size/speed tradeoffs in the generated, DFA, scanner also has the effect of raising the hard limit on the number of NFA states (from 32000 to about 231), but I already feel dirty just having looked at the code enough to discover this, so I’m going to stop digging while I’m ahead.
You may recall a month and a half ago I posted Notes on the Cross-Platform Availability of Header Files and then promptly had to take most of it down because it was insufficiently researched. Well, the research is ongoing, but I’ve got a shiny new set of results, some high-level conclusions, and several ways Viewers Like You can help!
First, the high-level conclusions:
- Except perhaps in deeply-embedded environments, all of C89’s library is universally available.
- Code not intended to run on Windows can also assume most of C99 and much of POSIX. The less-ubiquitous headers from these categories are also the less-useful headers.
- Code that is intended to run on Windows should only use C89 headers and
<stdint.h>. If MSVC 2008 support is required, not even
<stdint.h>can be used. (Windows compilers do provide a small handful of POSIX headers, but they do not contain the expected set of declarations!)
- Many different Unix variants ship a similar set of nonstandard headers. We don’t yet know whether the contents of these headers are reliable cross-platform.
- There is a large set of obsolete headers that are still widespread but should not be used in new code. This is underdocumented.
If you want to help, we need more inventories (especially for OSes further from the beaten path), and I’m also very interested in improvements to the giant generated HTML table. Y’all on Planet Mozilla can probably tell I’m not a Web designer. If you are an old beard, there are also places where I’m not entirely sure of my methodology – see the README in the source repo.
These header files are guaranteed to be available in a C89 hosted environment. All interesting portability targets nowadays are C89 hosted environments (bare-metal environments are still relevant, but not as portability targets).
Beyond C89, interesting portability targets divide into three classes. Complete Unix environments are always compliant with C99 and POSIX.1-2001 nowadays, but not necessarily with all of the optional modules of the latter, nor with any more recent standard. Windows has several different competing C runtimes, some of which offer more C99 support than others, and none of which are at all conformant with POSIX. Finally, the major embedded environments are presently all cut-down versions of a specific identifiable complete Unix or of Windows. Those that are derived from Unix usually have most of the POSIX headers but may be missing a few.
EDIT: Everything after this point in the original version of this post was insufficiently thoroughly researched and may be wrong. Corrected tables will appear Real Soon. If you are interested in helping me with that, please see https://github.com/zackw/header-survey.
If you find that Emacs on OSX fails to pick up the same
$PATH setting that you get in command line shells, instead defaulting to an impoverished default that doesn’t include (for instance) anything installed via MacPorts:
(add-hook 'after-init-hook #'(lambda () (setenv "PATH" (with-temp-buffer (call-process "/bin/bash" nil (list (current-buffer) nil) nil "-l" "-c" "printf %s \"$PATH\"") (buffer-string)))))
I am only embarrassed that I put up with the brokenness for as long as I did.
This PUBLIC SERVICE ANNOUNCEMENT is brought to you by the I JUST WASTED AN HOUR ON THAT Foundation:
Do you suffer from mysteriously hanging autotools processes? Or perhaps other mysteriously hanging processes? If so, you may have a problem with your file locking, and the IJWAHOT Foundation recommends you compile and run this program on the computer with the problem, preferably under strace or equivalent. If it, too, hangs, then you do indeed have a problem with your file locking. The Foundation does not presently know the cause of this problem, but we suspect that it is NFS’s fault somehow. If you do know the cause of this problem, we would love to hear about it in the comments.
for the sake of argument
that you had a giant list
of partial URLs
(you know, like
and you needed to canonicalize them
and chase redirects
and remove duplicates
and dead sites
and further you were aware
that this is much harder than it might sound
not to mention
that many websites do not like urllib
you might be looking for this program
which was written by me
with a little help from serge broslavsky.