Clib Maintenance

From Open Watcom

Revision as of 10:13, 22 March 2010; view current revision
←Older revision | Newer revision→
Jump to: navigation, search

This page is intended to collect the objectives and todo items for maintenance and restructuring of the Open Watcom C runtime library (clib).


The Good

A list of advantages and positives for the current clib which should be retained or even improved, in no particular order:

  • Compact and modular. Suitable for static linking.
  • Portable. Supports a variety of operating systems, relatively easy to add support for new platforms.
  • Compatible. Provides full ISO C90 and substantial ISO C99 compliance, as well as compatibility with the Microsoft C runtime.
  • Balanced. Has a good balance of performance and features.

The Bad

A list of general disadvantages and things that need to be improved, in no particular order:

  • Poorly structured source code. Platform specific code is not cleanly separated from generic logic, making the source code difficult to read and modify.
  • No stable DLL interface. The lack of a stable interface means every compiler release links against a different DLL runtime.
  • Tricky initialization. This is more of a documentation problem rather than an actual bug. The current initializer model works well and has some interesting advantages (3rd party code can easily plug into it), but it is poorly documented. In the past, subtle and very difficult to track bugs were caused by incorrect initialization code.
  • Incomplete C99 implementation. Some C99 functions are missing, although mostly relatively esoteric ones.


Some ideas for restructuring the clib source code. The intent is making the source easier to read, maintain, and extend, without any intentional changes in functionality or performance.

Separating OS independent code

It would be worthwhile to clearly identify library routines which are entirely independent of the operating system. Function such as strlen() only depend on the calling convention and memory model, but not on the OS. Thus strlen() for Win32 is the same as for 32-bit OS/2 or 32-bit extended DOS. We are currently not taking advantage of that.

Separating OS specific layer from generic code

In cases where code does depend on OS specifics, there is often poor separation between the truly OS specific parts and the generic implementation. This is partly historical, as the clib was originally written for DOS and over time ported to additional platforms. The current code tends to contain far too many ifdefs and is very hard to read.

Cleaning up startup code

The startup code is an extreme case of the above. There are many almost, but not quite identical source files for various platforms. It is very difficult to understand what is actually executed during program startup. This issue is different from the poorly documented library initializers (those called by clib/startup/c/initrtns.c).


A list of other potential changes which would improve the clib.

  • Debug builds. It could be advantageous to ship debug builds of the most commonly used libraries. That would also include additional sanity checks (some are already implemented in the code). That would save users valuable debugging time when they pass invalid parameters to the clib. Some debug builds are already produced by default, but not shipped.
  • Separate buildable clib. Related to the above, it could be helpful to make the clib source code available either as part of the standard install or as a small separate package.
  • Better granularity. Especially the Win32 and extended DOS clib builds often link with many unneeded routines. The OS/2 and 16-bit DOS clibs, on the other hand, had been tuned to break many unnecessary dependencies and only link in truly necessary code. This would make executables smaller and likely improve start-up times as well.
  • Aliases. The clib currently uses brute force aliases to implement symbol mapping (e.g. 'open' to '_open'). The aliases are generated automatically in clib/alias. Maintenance is not difficult (editing clib/alias/gen/aliases.lst), but there is both speed and size penalty for using them; jumps are expensive and in size-constrained environments, the extra bytes add up. A much better solution would be using symbol aliases ala OLDNAMES.LIB used by Microsoft tools. That way, the linker would resolve aliased symbols without incurring any penalties.
  • Build speed-ups. Building the complete clib currently takes relatively long time. Possible improvements include: Reducing the number of directories by merging some projects. Parallel builds. Building common OS-neutral routines only once.
  • Cross model cg helpers. (Not strictly part of the clib) Currently each clib build contains code generator support (clib/cgsupp) routines built for the specific memory model with identical names for all models. The problem is that mixed model code may end up being either inefficient or restricted. Other 16-bit compilers (Microsoft, Borland) provide helper routines whose names reflect the model - effectively each code variant has a unique name. The code generator can then flexibly reference near or far helpers as needed.
  • Separate cg helper library. Related to the above, it could be useful to ship the cgsupp libraries separately and cleanly distinguish between the C library proper and the code generator support routines.
  • Mixing 16-bit and 32-bit code. Because of 48-bit pointers, it should be possible to build 16-bit DOS executables that uses 32-bit registers and 48-bit pointers. [What does this have to do with the clib? It would be a compiler feature.]
  • POSIX compliance. There should be a generic POSIX interface + OS dependent routines needed to implement it. The socket interface should be extended to include more than Linux target, and OS depedendent and independent parts should be separated.
  • Non-IBM removal. The clib still contains some code to support NEC PC-98 machines which have not been built since the 1990s and the support probably doesn't even work. The "Non-IBM" code should be removed.
Personal tools