[comp.emacs] Naughty, naughty!

drw@cullvax.UUCP (Dale Worley) (03/05/87)

al@seismo.CSS.GOV@siac.UUCP writes:
> the problem stems largely from the fact that an int 
> is not the same size as a (char *).  the GNU code makes this 
> general assumption, and it's probably is correct for any machine,
> except for a '286.  

What?  RMS violating one of the primary rules of portability?  Ech!

Dale
-- 
Dale Worley		Cullinet Software
UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw
ARPA: cullvax!drw@eddie.mit.edu

ihm@nrcvax.UUCP (03/20/87)

al@seismo.CSS.GOV@siac.UUCP writes:
> the problem stems largely from the fact that an int 
> is not the same size as a (char *).  the GNU code makes this 
> general assumption, and it's probably is correct for any machine,
> except for a '286.  

... or '186 or 8086.  It wouldn't be such a crime to refuse to support
silly little toy architectures, except for the fact that there are
some of us that have no choice but to work on them, and could benefit
from having a real editor.  There ARE reasonable emacs subsets, of
course, (i.e. MicroEmacs, Epsilon, etc.), so it may not be such a
terrible thing.

I saw a comment needling RMS for 'violating a primary rule of
portability', but with the x86, Intel violates common sense enough to
create far more portability issues than RMS's oversight.

							<>IHM<>

ron@brl-sem.UUCP (03/22/87)

In article <812@nrcvax.UUCP>, ihm@nrcvax.UUCP (Ian H. Merritt) writes:
> ... or '186 or 8086.  It wouldn't be such a crime to refuse to support
> silly little toy architectures, except for the fact that there are
> some of us that have no choice but to work on them, and could benefit
> from having a real editor.  There ARE reasonable emacs subsets, of
> course, (i.e. MicroEmacs, Epsilon, etc.), so it may not be such a
> terrible thing.
> 
> I saw a comment needling RMS for 'violating a primary rule of
> portability', but with the x86, Intel violates common sense enough to
> create far more portability issues than RMS's oversight.
> 
C'mon, lets be fair.  For someone who just finished a C compiler,
you're being awfully short sighted.  CHAR * and INT are two seperate
types which need not have any relationship to each other.  It isn't
just "toy" machines using the Intel chips that have the problem.
Machines with 64 bit wordsizes generally make the address sizes smaller
to be reasonable.Other machines, int is smaller than char * and long.
Someone went and found the small number of cases in Gnu EMACS where these
assumptions were made and RMS scoffed and refud to make the correction,
which ioutright arrance.

A system that is going to be claimed as the saviour of the people through
free hardware ought to work on the not-free but cheap hardware of the
masses.

-Ron

davidsen@steinmetz.UUCP (03/23/87)

In article <812@nrcvax.UUCP% ihm@minnie.UUCP (Ian Merritt) writes:
%al@seismo.CSS.GOV@siac.UUCP writes:
%% the problem stems largely from the fact that an int 
%% is not the same size as a (char *).  the GNU code makes this 
%% general assumption, and it's probably is correct for any machine,
%% except for a '286.  

The problem stems from the fact that X3J11 and K&R agree that
assigning pointers to integers may lead to non-portability. When
writing portable code the only data object which may hold an
address is a pointer *to the same data type or void*. The fact
that may compilers allow this is not a good reason to do it.
%
%... or '186 or 8086.  It wouldn't be such a crime to refuse to support
%silly little toy architectures, except for the fact that there are
       ^^^^^^^^^^^^^^^^^^^^^^^^
	and PDP-11??
%
%I saw a comment needling RMS for 'violating a primary rule of
%portability', but with the x86, Intel violates common sense enough to
%create far more portability issues than RMS's oversight.

If you want to put the heat in the right place, how about the
fact that all 80x86 C compilers allow 32 bit integers (long) and
no one has given the option to make the default size of int 32
bits? I (verbally) suggested this to Microsoft for their v3.0
compiler while it was in beta test, and was told that it would
make the code too slow. Not as slow as editing the source by
hand of reinventing the wheel! There are gobs of programs
written by people who were struggling so hard to make a program
work, or so ignorant of good coding practice, that they wrote
trash code which does something useful.

-- 
bill davidsen			sixhub \
      ihnp4!seismo!rochester!steinmetz ->  crdos1!davidsen
				chinet /
ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)

rbj@ICST-CMR.ARPA.UUCP (03/26/87)

? %... or '186 or 8086.  It wouldn't be such a crime to refuse to support
? %silly little toy architectures, except for the fact that there are
?        ^^^^^^^^^^^^^^^^^^^^^^^^
? 	and PDP-11??

There is nothing wrong with the PDP-11 except it's size. It's
addressing is uniform and pointers mix well with integers.

Veterans of net.lang.c will recall my view on the desirability of
having pointers be the same size as integers. I do not wish to
reopen that can of worms here.

? bill davidsen			sixhub \
?       ihnp4!seismo!rochester!steinmetz ->  crdos1!davidsen
? 				chinet /
? ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)

	(Root Boy) Jim "Just Say Yes" Cottrell	<rbj@icst-cmr.arpa>
Now, I think it would be GOOD to buy FIVE or SIX STUDEBAKERS
and CRUISE for ARTIFICIAL FLAVORING!!

jgp@moscom.UUCP (03/30/87)

[This doesn't have much to do with emacs so I'm directing followup to lang.c]
In article <1318@steinmetz.steinmetz.UUCP> davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr) writes:
%In article <812@nrcvax.UUCP> ihm@minnie.UUCP (Ian Merritt) writes:
%%al@seismo.CSS.GOV@siac.UUCP writes:
%%% the problem stems largely from the fact that an int 
%%% is not the same size as a (char *).
%...
%%... or '186 or 8086.  It wouldn't be such a crime to refuse to support
%%silly little toy architectures, except for the fact that there are
%       ^^^^^^^^^^^^^^^^^^^^^^^^
%	and PDP-11??
Both (char *) and (int) are 16 bits on our (and I assume most) pdp11's.

%If you want to put the heat in the right place, how about the
%fact that all 80x86 C compilers allow 32 bit integers (long) and
%no one has given the option to make the default size of int 32 bits.
Such an option would be great for 680[01]0's too.  In the name of
portability everyone makes int's 32 bits even though the 020 was
the first 68k to be able to multiply 32 bit quanitities in a timely
fasion.

Does GnuC offer the ability to select the size of an int?  16 bit
ints and 32 bit pointers mean that some standard unix calls need
to take longs instead of ints (malloc, strncpy etc.) but the implicit
casting of parameters possible in ANSI C could make this painless
enough to consider.
-- 
Jim Prescott	rochester!moscom!jgp