Third public review of X3J11 C (a scientist speaks up)

[Henry Spencer]

In article <887 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
>...  I do not have the time to attend meetings on software.

In other words, you want it fixed, but you can't be bothered investing your
own time and effort in getting it fixed?  Don't expect much sympathy.
Standards are hard work; if you can't be bothered helping with it, those
who do put in long hours on them are likely to feel that you don't really
care all that much.

> What about fixed-point (_not_ integer) arithmetic?

What about it?  Last time I did something along those lines, there wasn't
any formidable difficulty in implementing it on top of integer arithmetic.
That was a long time ago, and the stuff I was doing was specialized and
simple, mind you.

> What about the use of overflow?

A nice idea, but it's hard to make it portable.

> What about division with simultaneous quotient and remainder?

Already in X3J11 C; see div() and ldiv() in section 4.10.6.  If your
compiler supplier doesn't implement them or implements them inefficiently,
complain to him, not to X3J11 or to the net.

>What about an operation or function returning a string of values?

What about it?  Can be done right now, although a bit clumsily, using
pointers; see scanf for an example.  It's not at all clear that adding it
as an explicit construct would improve efficiency; in fact it could well
reduce it.

>What about table-driven branches?

See the "switch" construct, which has been in C all along.  If your
compiler doesn't do this well, again, complain to the supplier.

>What 
>about inserting new operators, using the processor syntax to specify the
>argument structure of these operators?

Again, perfectly possible now if you're willing to live with distasteful
syntax (function calls).  The past experiments with user control of syntax
have mostly been limited successes at best.

>In fact, what about using the 
>easy-to-use hardware operators on most machines?  A good example is &~,
>which is more useful than &, and is hardware on many machines, including
>the ones for which C was initially written...

And which any sensible compiler on those machines will use if you write
x & ~y, just as you'd expect.  See above comments on compiler defects.

>How many useful instructions have disappeared from hardware because they
>do not occur in the HLLs?

How many useless instructions have appeared in hardware because some clot
had the mistaken idea that they could be useful to HLLs?  Exacting a speed
and cost penalty from the customers as a result of the extra complexity,
too.  Such things are always compromises.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry at zoo.toronto.edu