C's syntax (was Re: Python Formatted C Converter (PfCC))

[Alex Martelli]

"William Tanksley" <wtanksle at dolphin.openprojects.net> wrote in message
news:slrn8veadt.roh.wtanksle at dolphin.openprojects.net...
    [snip]
> I don't mind the syntax, myself; the hard part for me is how incredibly
> poorly designed the standard library is.  A good library is able to catch
> mistakes; C's library usually 'detects' errors by corrupting memory and
> dying later.

Well, "catching mistakes" within a language of very low semantic
level and its library is not easy -- and I think C's level was just
right for its time & target (and still comes in handy often).

Still, there are other design defects.  For example, the idea of
having strcpy and strcat return (rather uselessly) the same
value that was passed as the first argument, rather than
something useful, such as the pointer to the _end_ of the
resulting string (so putting a long string together from small
pieces ends up being O(N squared) if you want to use the
C standard library -- you have to use another, custom library
[or manipulate the pointers directly] to get the 'natural'
O(N) performance).  Or the useless inconsistencies in stdio
routines about where the FILE* parameter goes.

However, patching _these_ up with your own routines (or
macros) is very easy, fortunately.  Pity that everyone has to
do it anew (or suffer the standard library's strange design
limitations).

> immediately).  C's library, when thus tested, detected almost none of the
> misuse.  It's a design flaw, not something a compiler can easily fix.

It's a design _decision_ -- being low-level and straining for
performance, at the cost of error-checking or ease of use.  I
would not call this decision a _flaw_, per se.


Alex