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