🚀 go-pugleaf

In article <EE-B=O2@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>In article <4641@inews.intel.com> bhoughto@pima.intel.com (Blair P. Houghton) writes:
>> Old chesnuts crack hard...

And old cocoanuts post garbage...

>> The most general, and therefore most valuable, way to define NULL is
>> to simply map it to the digit 0.
>
>And you're working at Intel...

So?  Not everyone at Intel is on the Intel*86(tm) design
teams (but I _do_ have a poster of a plot of an 80386DX(tm)
behind my chair, so if you want to you can go right ahead
and believe that I drew it freehand...), and I couldn't
tell you if _anyone_ at Intel is the owner of the design of
_any_ compiler.

>On an 80x86 (x<3), there exist models where
>int = 16 bits, pointer = 32 bits. On such a machine,
>
>	execl("/bin/sh", "sh", "-c", "echo", NULL);
>
>(which is a common idiom in UNIX source groups) will display amazing
>things, assuming you don't get a core dump...

1.  I am not responsible for bad/typical/good design of compilers.
2.  I am not responsible for your incorrect use of the semantics
of function calls.
3.  I do, however, feel responsible for your education and
edification as long as you are part of my community, so I
will remind you that we've been 'round and 'round the
argument-size vs. parameter-size ambiguity bush, and that
the standard defines this problem, even if it is a bit
shrouded in documentational mumbo-jumbo.

				--Blair
				  "But if you ever need an Intel186(tm)-based,
				   custom microcontroller, give me a call and
				   I'll explain how I'm not in sales, either..."