Why I'm wrong about what sort of APIs C's stdargs allows
One of the things that blogging gives me is the chance to be verywrong in public. Yesterday , I claimed thatC's stdargs didn't let you peel some arguments off the front of a va_list and then pass the shortened list to another function,such as vprintf() . Well, no, and now I'll tell you why I'm wrong.
I'm clearly wrong in practice on x86 Unix machines with gcc, as a simpletest program easily demonstrated once
How I fixed Google's search results redesign
I really dislike Google's redesign of their search results, because theycommit one of my great irritations ; they putsite navigation on the left side (where it cuts off content in narrowwindows) instead of on the right (or on the bottom, or nowhere). Aftera few days of staring at the new design and grinding my teeth, I decidedto fix it.
Since I use Firefox, the modern way of fixing this is probablya Greasemonkey script. However I don't use Greasemonkey for
An example of an API that you can't do with C stdargs
(This is a followup to yesterday's entry .)
Update : I'm actually completely wrong about this, both in practiceon x86 machines with gcc and, I believe, in standards-compliant theory,as brought to my attention by nothings in comments.
One general class of impossible-in-C varargs APIs is heavily polymorphicdispatch APIs where you need to dispatch to one of several differentvarargs functions that have different constant arguments. Here is agratuitous (and probably bad) API example:
The limitations of C's varargs support
I've noted before that dealing with varargs functionsin C is vaguely annoying (although not as annoying as in the days beforethe ANSI C stdarg support). One of those annoyances is that C's stdargsupport is limited compared to what you can do in languages with firstclass support for variable argument counts.
The core limitation in C is that you can't manipulate the list ofvariable arguments that your function gets. Instead you have twochoices; you can pass it completely unaltered to a function that
Why RPM's .rpmnew files don't work in practice
In theory, RPM has a solution to yesterday's bad package upgradeproblem by way of what are generally called.rpmnew files. When you've modified a configuration file, update theRPM it comes from, and the new version of the RPM has also changed theconfiguration file, RPM does not overwrite the configuration file butinstead creates This does not work in practice. The problem is that there are entirelytoo many false positives; it I spent a greater part of today discovering how and why What happened to cause this is a badly considered package update. Inthe beginning of RHEL I recently needed to do something to our MoinMoin-based wiki. As it wascurrently configured, doing that thing was a parade of annoyance, so Iwound up rummaging through the configuration options and found one thatsignificantly simplified my task. Now, suddenly, I had a dilemma. Our existing MoinMoin configuration didn't have this option turned on,and the person who configured our MoinMoin instance isn't around anymore to be asked questions. So, had they overlooked this option whenthey set up the wiki Last entry I mentioned that I now had a theoryabout our odd switch failure with jumbo frames, where after a powercycle the switch would start doing jumbo frames remarkably slowly untilyou went into the configuration system and re-selected the 'do jumboframes' option. This is theory. As I've mentioned before , modern switcheshave two parts; a high speed switching core and a slower managementprocessor that handles everything else. If the jumbo frames weren'tbeing handled by the switching core but were instead When we were initially designing our iSCSI SAN environment, we plannedto use jumbo frames; it was just an obvious thing to do. Then we triedto find an inexpensive 16 or 24 port gigabit Ethernet switch thatactually did jumbo frames completely correctly. To skip to the punchline, we failed. Worse, in the process offailing it became obvious that jumbo frames were a dangerousswamp. (Since jumbo frames did not get us any real performanceincrease , we didn't then try expensive switches.) Here is a mistake that we've actually made more than once. We have NFS fileservers , and to enable basic NFS server failover ) each of them has both itsreal hostname (and IP) and a virtual IP alias. The real hostname isrelatively long (we use the names of cities that start with 'san'); thefileserver's virtual hostname is short ('fsN' for some single-digit N).The result is that when we log into machines, we almost always use
An illustrated example of how not to do package updates
smartd wasnot monitoring our disks on several of our Red Hat Enterprise 5 based iSCSI backends . The quick summary is that if yourRHEL 5 machine was installed some time ago (or installed recently froman old installer disk) and upgraded since then, smartd may not bemonitoring all of your disks; this is all but certain if you've recentlyadded new disks.
You should also document why you didn't do attractive things
A theory about our jumbo frame switch firmware bug
Why we don't use jumbo frames for iSCSI: a cautionary tale on testing
A sysadmin mistake: shooting your virtual foot off
Menu