Pith. Sign in

REVIEW

Language Support for Optional Functionality

PaperPDF from arXiv

data files

ReviewThe objections and verdict, as JSON Paper breakdownThe authors' claims, conditions and measurements, as JSON Signed receiptProof this review has not been altered
X Bluesky LinkedIn Reddit Hacker News
Joy Mukherjee, Srinidhi Varadarajan

Programming Languages · Submitted 6 Mar 2006 · 12 references

Pith's verdict: A clean but incremental idea for checking function availability at runtime, with a candid paper that oversells its variable-handling and backs its claims with a single unstatistical performance measurement.

T0 · AI review

How this review was made: An AI referee (deepseek-v4-flash) read the paper on August 28, 2026 and answered a fixed list of questions about it. T0 is the starting level every paper gets. The levels describe how deeply Pith has checked the paper, never the authors.

  1. T0 AI review An AI read the paper and answered a fixed list of questions.
  2. T1 Audit Automatic checks that the references and files the paper relies on exist and match.
  3. T2 Compute The paper's code or calculations re-run with the same results.
  4. T3 Formal statement The claims written out in a formal math language a computer can read.
  5. T4 Proof Those claims proved, and the proof checked by computer.

How Pith checks papers →

· 4 major objections · 5 minor · Ask about this paper · The compiled record · Read the full review →
Challenge this review Comment (0) Read on arXiv ↗
Cite ▾
arXiv IDcs/0603021 (version 1)
Pith ID67IJOUEV, Pith's permanent record of this paper and its review
CitationJoy Mukherjee, Srinidhi Varadarajan. "Language Support for Optional Functionality." arXiv:cs/0603021 (2006). https://pith.science/paper/67IJOUEV
Cite this reviewBibTeX for Pith's review of this paper
Claim paper

Why Pith says this

Highlight any text to comment on it.

Referee report

How Pith checks papers → · Full audit of this paper →

The paper

The paper claims

This paper claims that an ordinary-looking if statement, compiled into a GOT-entry check, lets compiled C programs on UNIX automatically adjust to optional libraries being present or absent, without rebuilding.

The reading

This paper proposes a function availability check (FAC): a construct with the syntax of an ordinary if statement that tests, at run time, whether an external function has a valid definition before the call is executed. The aim is to let compiled C programs on UNIX automatically adjust to the presence or absence of optional code by adding or removing shared libraries, without rebuilding the application. The claim is that this combines the flexibility of dynamic libraries (dlopen/dlsym) with the ease of utility libraries, while reducing development complexity, measured as fewer lines of code. A preliminary implementation and a small DILLO browser experiment indicate that a FAC-based version costs roughly the same initialization time as a libdl-based one.

What carries the argument

The machinery is the pairing of a specialized if construct with a lenient ELF loader. At compile time, a redundant-looking if statement whose condition is an external function is recognized and compiled into an assembly check of the function's GOT entry: a NULL entry means skip the block, a valid address means call it. The loader is the second half: it ignores missing shared objects at startup and writes NULL into the GOT slots of any external function it cannot resolve, under the assumption that every such reference is wrapped in a FAC. Weak aliasing plus position-independent compilation is described as an alternative implementation that avoids compiler changes but costs extra preprocessor directives and larger generated code.

Extended reading notes

Core claim

The central discovery is that function availability can be surfaced as a language-level if test, backed by a loader that tolerates missing libraries. In the compiled form, FAC reads the target function's Global Offset Table entry and jumps over the guarded code when that entry is NULL; a non-NULL entry means the function is defined and the call proceeds. The paper treats this NULL check as safe even though an undefined function has no NULL address, because the GOT entry is under the loader's control. A modified ELF loader ignores missing utility libraries at startup and nullifies GOT entries for unavailable external functions, so the runtime linker is never invoked on a guarded reference. With this machinery, a compiled program automatically drops a feature whose library is removed and regains it when the library is restored after a restart.

Load-bearing premise

Every reference to a possibly missing function must be wrapped in a FAC, because the loader intentionally ignores absent libraries and will crash on any unguarded call; the paper supplies no static analysis or tool to enforce that discipline.

Editorial extensions

If this is right

  • Deleting an optional library from a directory changes program behavior without recompiling or relinking the core executable.
  • Adding back a previously missing library restores the feature at the next program restart, since libraries are loaded once at startup.
  • Optional-feature code can be written as ordinary if blocks instead of explicit dlopen, dlsym, and NULL-check sequences, removing the libdl dependency from the core codebase.
  • FAC does not give runtime selection among several alternate plugins that expose the same interface; it only handles presence or absence of distinct features.
  • Initialization-time overhead measured on DILLO is comparable to a libdl-based implementation, with variations attributed to lazy linking rather than to the availability check itself.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A static analyzer that verifies every reference to a possibly absent function is inside a FAC would close the paper's main safety gap; nothing in the paper prevents a single unguarded call from crashing the program.
  • The same GOT-nullification trick could support feature discovery for other pointer-based indirections, such as weak data symbols or versioned function entries, though the paper stops at functions.
  • A larger-scale line-of-code comparison across several optional features would test whether the LOC savings hold beyond the single DILLO case, where the saving was only 4 lines versus 23 extra lines for dlopen/dlsym.
  • If FAC were paired with periodic re-checking rather than one-time load-time resolution, newly installed libraries could be picked up without restart, but that is beyond the paper's design.
Original abstract

We recommend a programming construct - availability check - for programs that need to automatically adjust to presence or absence of segments of code. The idea is to check the existence of a valid definition before a function call is invoked. The syntax is that of a simple 'if' statement. The vision is to enable customization of application functionality through addition or removal of optional components, but without requiring complete re-building. Focus is on C-like compiled procedural languages and UNIX-based systems. Essentially, our approach attempts to combine the flexibility of dynamic libraries with the usability of utility (dependency) libraries. We outline the benefits over prevalent strategies mainly in terms of development complexity, crudely measured as lesser lines of code. We also allude to performance and flexibility facets. A Preliminary implementation and figures from early experimental evaluation are presented.

The compiled record

The paper's own sentences, arranged, kept beside the review and separate from it. Each label is drawn from a closed vocabulary; the number beside it is the probability the classifier gave that label. Numbers in the tables are the authors', checked by code. No sentence in this record was written by a model.

Compiled by classifier-1.13-20260917 via OpenRouter, question bank abstract-p1-20260923, 2026-09-23: 1 request, 6,584 input tokens, $0.0003 reported.

What the abstract itself states, as probabilities: claims first 0.04 · states limitation 0.55 · human participants 0.03 · controlled comparison 0.15 · randomized assignment 0.01 · states quantitative result 0.13 · compares with prior results 0.77 · mentions code or data availability 0.13.

The abstract, sentence by sentence

arXiv listing abstract v1. Results and the main claim are underlined; .

We recommend a programming construct - availability check - for programs that need to automatically adjust to presence or absence of segments of code. The idea is to check the existence of a valid definition before a function call is invoked. The syntax is that of a simple 'if' statement. The vision is to enable customization of application functionality through addition or removal of optional components, but without requiring complete re-building. Focus is on C-like compiled procedural languages and UNIX-based systems. Essentially, our approach attempts to combine the flexibility of dynamic libraries with the usability of utility (dependency) libraries. We outline the benefits over prevalent strategies mainly in terms of development complexity, crudely measured as lesser lines of code. We also allude to performance and flexibility facets. A Preliminary implementation and figures from early experimental evaluation are presented.

background contribution method result interpretation main claim

What the classifier reports for each sentence. The number is the probability it gave the label.
#sentencerolethe authors' own workstates the main conclusionstrength
s0 We recommend a programming construct - availability check - for programs that need to automatically adjust to presence or absence of segments of code. contribution 0.96 0.39 0.47 asserted 0.71
s1 The idea is to check the existence of a valid definition before a function call is invoked. method 0.85 0.22 0.08 asserted 0.99
s2 The syntax is that of a simple 'if' statement. method 0.94 0.42 0.04 asserted 1.00
s3 The vision is to enable customization of application functionality through addition or removal of optional components, but without requiring complete re-building. contribution 0.68 0.17 0.19 asserted 0.63
s4 Focus is on C-like compiled procedural languages and UNIX-based systems. limitation 0.61 0.17 0.03 asserted 0.97
s5 Essentially, our approach attempts to combine the flexibility of dynamic libraries with the usability of utility (dependency) libraries. contribution 0.58 0.40 0.16 asserted 0.61
s6 We outline the benefits over prevalent strategies mainly in terms of development complexity, crudely measured as lesser lines of code. result 0.44 0.70 0.22 asserted 0.93
s7 We also allude to performance and flexibility facets. contribution 0.73 0.48 0.05 hedged possibility 0.60
s8 A Preliminary implementation and figures from early experimental evaluation are presented. contribution 0.93 0.93 0.06 asserted 0.99

What kind of paper the classifier reports this is: method or tool 1.00 · evidence from observation or experiment 0.93.

What was examined, and what was not

sources read
  • arXiv listing abstract v1
not examined
  • full text
  • figures and tables
  • references and citing sentences
  • relations to other papers
levels run
  • P abstract
not run
  • S sections
  • T body sentences
  • C citations
  • R cross-paper relations

Every quoted sentence on this record is the authors'. Every label is from Pith's closed vocabulary, with the probability shown beside it. Every number in the measurements table is the authors', checked by code. Record as JSON

Figures
Figure 1. A customizable web-browser can comprise optional support for images, flash, help, and other tools. In this paper, we recommend a programming construct – availability check – for programs that need to auto￾matically adjust to presence or absence of segments of code. Focus is on C-like compiled procedural languages and UNIX-based systems (section 2). Essentially, our Core browser flash tools jpeg gif png help Required code Optional code
Figure 3. Dynamic libraries are used for optional appli
Figure 4. Syntax of FAC is like a simple ‘if’. The intuition is that an available or defined function has a valid non-NULL address associated with it while an undefined function does not. Note that, unlike variables (including those of type function pointer), an undefined function should not be misconstrued to have an address with a NULL value. There is simply no notion of an associated address with respect to undefined functions. Naturally, FAC is pertinent to external functions only, since internal functions are available by definition. Note that FAC is a type less construct. This is…
Figure 5. DILLO handler for MIME types. The handler
Figure 7. FAC assembly for the source in Figure 3.
Figure 8. A FAC-based approach did not result in dis

Showing 6 of the paper's 8 figures. See all figures in the PDF ↗ Figures reproduced from arXiv:cs/0603021 by the authors.

References

Discussion

Disagree with the review, or know something it missed? Leave a comment, highlight any passage above to comment on it, or challenge this review formally.