Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: net.lang.c
Subject: Re: C Builtin Funxions
Message-ID: <2554@utcsri.UUCP>
Date: Sun, 13-Apr-86 03:58:45 EST
Article-I.D.: utcsri.2554
Posted: Sun Apr 13 03:58:45 1986
Date-Received: Sun, 13-Apr-86 04:45:42 EST
References: <2524@brl-smoke.ARPA>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 83
Summary: I'm a ramblin' guy...

In article <2524@brl-smoke.ARPA> rbj@icst-cmr (root) writes:
>> That may be the original practice, but the X3J11 (ANSI C) drafts, now quite
>> clearly say that all functions defined in the library are reserved (ie, you
>> can't redefine them), and may be builtin to the compiler.  I believe that the
>> /usr/group standard (& probably P1003) reserved every function from all major
>> UNIX* variants.  It may be that redefining these reserved library functions
>> will continue to work in *YOUR* implementation, but it's not guaranteed.
>> 
>Before I flame at the bogosity of this proposed madness, I will entertain
>suggestions as to why this decision was made. Fire away.
>
>On another note, `sizeof' is NOT a builtin funxion. It is merely a funny
>way of writing an implementation defined constant.
>
Many thoughts. First of all, when I read the suggestion that sizeof might
be a builtin function, I definitely took that as a gag, and I am tired of
reading about why it isn't. Secondly, Jim, you may be interested to know
( if you don't know already ) that, in Britain, the correct spelling of
'connection' is 'connexion'. :-)

Why should library functions be reserved? I haven't seen X3J11 so I don't
know which or how many functions they are going after, but on the
surface it seems a good idea to reserve things like getc and printf
and fopen and so forth. It will make it easier to port stuff - but on
the other hand, like any standard, it may well stifle improvement.
I don't think it would be smart to reserve the whole friggin'
library, though - this is just silly. Does this include things like
getenv and getppid and symlink that may not have meaning on a
non-UN*X system?

Suppose you had an OS where getc(f) could be done by sticking f
in a register and executing a processor trap. A compiler recognizing
built-ins could generate in-line code for this.

On  related point ( I'll explain why ), do y'all remember "Weird C
behaviour"? One of the problems being that printf was being passed the
wrong types?

Well, lint can't catch this sort of thing because it is told by
/*VARARGS*/ to keep its cotton-picken hands off any call of printf.
Anyway, in order to check this, it needs to know (1) that printf,fprintf,
sprintf are special cases, (2) how to interpret printf format strings.
The format may be known only at run-time: printf(fmt_string,...).
However, in view of the facts that printf's are frequent, and that mistakes
in parameter types are fairly common, and that 95% of printf calls have
string constants for formats, I would like to see lint do this. If
the format parameter was not a string constant, you would be on your
own of course. The following is a borderline case:

	printf( c<' '|| c>'\176'? "\\%3o":"%c", c);

It would probaby be asking too much for lint to recognize what was
going on, and then check *both* format strings - but it would be nice.
I do the above sort of thing once in a while. Anyway, so whaddya think?

Of course, the same sort of thing can be done for scanf - although
this is used less commonly.

If 'printf' and friends were to become *quote* built-in *unquote*
functions, this addition to lint would be even more justified.
Can you imagine redefining printf and then having lint tell you
that your format string was out to lunch?

Now for something completely different...
From: g-rh@cca.UUCP (Richard Harter)
>	Grumble, grumble.  Sorry, this is a real practical problem.
>	Let me give some context.  Suppose you are doing a high speed
>	sort of character strings.  Being a clever fellow you have
>	read the glossed over parts of the literature and have seen
>	that a math sort is O(n) rather than O(n log n).  You also
>	notice that it is cheaper to compare 4 bytes at once with
>	an 32-bit integer compare than to make 4 byte compares.

I'm not sure on this - isn't it ridiculous to do a mathsort of 32-bit
ints? In O(n) above ( for the mathsort) doesn't n become 2^32 rather
than the list size? If so, it would of course be even sillier for
larger ( i.e. reasonably-sized ) char strings.

'Bye for now...
-- 
"If you aren't making any mistakes, you aren't doing anything".
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg