Re: Portability of Lua

[William Ahern <william@...>]

On Tue, Apr 30, 2013 at 06:51:23PM -0700, Tim Hill wrote:
> 
> But the point is that the C "standard" leaves some things so open that
> it's very difficult to write code without making some guesses. Width of an
> integer?

If you could provide concrete examples, then it would be easier to discuss.

The byte width of any integer type is simply sizeof (type), and that's
sufficient for memory mangement. The arrangement of bits is almost always
inconsequential because one should always be operating on values without
concern for representation. unsigned char is guaranteed to never have any
padding bits, making it trivial to, e.g., load and store encoded byte
sequences from memory or a file. C is no worse than Java or C# here, and in
practice much easier to use. The marginal return on over-specifying behavior
the way Java does is almost nil.

(Also, exact-width unsigned types like uint32_t never have any padding bits
[and thus no trap representations], and C11 even provides alignof, so
masochists who really want to conflate value and represtation can actually
do so within the confines of the standard.)

> Behavior of C runtime functions? All have very subtle hidden assumptions.
> For example, when you call "malloc()" you assume that it won't take 5
> seconds to allocate memory, but the standard is silent on such issues as
> API overhead. Writing in standard C is a REQUIREMENT for portability, but
> not a GUARANTEE.

That's an odd argument to make. No general purpose language makes that
guarantee. Runtime limits are nearly impossible to standardize, although C
makes a passable attempt. Anyhow, on systems with pageable virtual memory,
even a block of memory already allocated can stall the whole execution
context. In any event C, just like Java or C#, is defined in terms of an
abstract "virtual" machine.

If you write your code using nothing but well-defined C, it's guaranteed to
compile with any C implementation. In many cases you can even use
unspecified and implementation-defined behavior in a portable manner.

Lua is a testament to the practicality of writing portable code. It does
make a handful of assumptions, but it chooses to do so. And while Lua code
is very clean and very strict C, it's not that exceptional. If you hang out
in the right forums (i.e. not the stackexchange, cargo-cult groups where the
notion of portability is already dismissed out-of-hand ;) you can see it
done on a regular basis.

Nobody said it's easy to write compliant C code, but if you don't have at
least one copy of a C standard on your desktop that you reference regularly,
you're not even trying. And compared to other languages with a written
specification, C is actually rather easy to wrap your head around.