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

William Tanksley wtanksle at dolphin.openprojects.net
Thu Oct 26 14:06:12 EDT 2000


On Thu, 26 Oct 2000 00:03:21 +0200, Alex Martelli wrote:
>"William Tanksley" <wtanksle at dolphin.openprojects.net> wrote in message

>> 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).

I'm not expecting detection of out-of-bound array references, mind you.
Nothing, in fact, that would take any additional CPU time.

For example, it's generally conceded that realloc has too many functions:
it does downsizing, allocation, and upsizing.  At least one of those
functions (preferably allocation) should be removed.

You mention below some problems with string length; these problems
continue and proliferate to form the many stack overwrite errors we all
know and love.  Although zero-terminated strings have many uses, many more
functions should be more helpful about the boundaries of the strings. You
suggest returning the end address; I would suggest returning the length,
since that's immediately useful even if you're not appending.

>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.

Ugh, that's true.

>Alex

-- 
-William "Billy" Tanksley



More information about the Python-list mailing list