🚀 go-pugleaf

In article <1991Mar29.064102.24914@Think.COM> barmar@think.com (Barry Margolin) writes:
> 	char buf[sizeof int];
> 	*(int *)&buf = 1;
> what is the value of buf[0]?  On some machines it will be 0, on other
> machines it will be 1, and some strange machines could produce other
> values.

So what? Just because code is portable doesn't mean it will produce the
same results on different machines. What's 32767 * 32767 in Ada?

The code works, is useful, and has well-defined results under any C
compiler. It can't be translated into portable Lisp code.

> Or did you mean "select among possibly available libraries"?

Yep, that one. It is not a failure of C that different C platforms
provide different nonstandard libraries, and an application that can
take advantage of such libraries is hardly ``loaded with
machine-dependent #ifdefs.''

> Don't different Unix flavors have different naming schemes for pseudotty
> devices?  I don't think SunOS has any libraries that deal specifically with
> pseudotty's; every SunOS program I've ever seen that uses them contains an
> inlined loop to find an available pty, open it, fork, etc.  It's really a
> shame, because they each have different assumptions about the maximum
> number of possible ptys, and frequently have to be updated when we increase
> the number of ptys.

Yes, it is, and wouldn't it be a lot simpler if all these assumptions
were isolated in a couple of configuration options in a single program?

> By your reasoning, a program that I implement by loading code into Lucid
> Lisp and dumping out the image is written in the language that Lucid Lisp
> is written in, even though I might not even know how to program in that
> language!

No. I didn't say elisp code was written in C. I said Emacs was written
in C. Just because it happens to come with a whole bunch of elisp
add-ons doesn't change the language Emacs is written in.

Would you say C is written in C, just because C platforms come with a
whole bunch of libraries that C programs can use?

---Dan