jeff@ISI-VAXA.ARPA (Jeffery A. Cavallaro) (09/09/85)
What Mr. Harris meant to say (he didn't say it too well) was the following: "short" and "long" are generic "int" types that should be used whenever a general purpose integer value is required. These types are meant to provide compatability on two levels: 1. PORTABILITY The ability to port code between different machine types and operating systems that support C. 2. NETWORK COMMUNICATION To enable network communication between different machines, a "short" is guaranteed to be 16-bits and a "long" is guaranteed to be 32-bits. This is either convention or standard, I am not sure which. If anyone knows if this is a printed standard, I would appreciate them sending me a message with the reference. When sending data over a network, the "byteorder(3N)" routines should be used to convert machine-dependant "short" and "long" types to a network standard byte order. When receiving these types, one should convert back to the machine-dependent forms. By the way: WHOLE STRUCTURES SHOULD NEVER BE TRANSMITTED OVER A NET DUE TO BYTE ORDER AND ALIGNMENT PROBLEMS. In contrast, the "int" type is a very machine-dependent type. It is made equivalent to a machine's natural word size. This type is needed if C is going to make any claims about being an "operating system capable" language. FLAME OF MY OWN: People such as Mr. Harris should be aware that not all people participating in this forum are experts. The question was a valid one, and deserved a reasonable response, not a better-than-thou dissertation. Such responses just intimidate people who might otherwise benefit by asking questions of this type. Jeff
ron@brl-tgr.ARPA (Ron Natalie <ron>) (09/09/85)
> To enable network communication between different machines, a "short" is > guaranteed to be 16-bits and a "long" is guaranteed to be 32-bits. This > is either convention or standard, I am not sure which. Actually, it is neither. Assuming short is 16 and long is 32 will get you into problems. If you have a machine with a word size longer than 32, you have no recourse than to make your longs the length of the word size, as it is a standard that ints can't be longer than longs. Those of us who work on 36 and 64 bit machines are well aware of this problem. The network standard lists the exact bit representation using pictures, not related to any machine or language. HTONS and the other byteorder routines are used in 4.2 code to byte swap when necessary. They are not part of any standard or convention outside of the 4.2. Bit fields are another source of network problems as there is currently no standard for the order of bits in a group of fields. > By the way: WHOLE STRUCTURES SHOULD NEVER BE TRANSMITTED OVER A NET DUE > TO BYTE ORDER AND ALIGNMENT PROBLEMS. No matter what you transmit over the net you have to be careful and there always ends up being some machine dependance somewhere. There is no such thing as a network alignment problem. The network is a string of octets (that's eight bit things, can't say bytes because some people actually have different byte sizes). > FLAME OF MY OWN: > People such as Mr. Harris should be aware that not all people participating > in this forum are experts. You certainly aren't.
jeff@isi-vaxa.ARPA (Jeffery A. Cavallaro) (09/10/85)
>> You certainly aren't
Right. Outside of VAXen, I am not. That is why I joined the forum...
By the way, the alignment problems I was speaking of have to do with
alignment of items within structures by different C compilers.guy@sun.uucp (Guy Harris) (09/11/85)
> FLAME OF MY OWN: > People such as Mr. Harris should be aware that not all people participating > in this forum are experts. The question was a valid one, and deserved a > reasonable response, not a better-than-thou dissertation. Such responses > just intimidate people who might otherwise benefit by asking questions of > this type. People who use the C language should be sufficiently expert that they understand that "long" and "short" should not be selected in favor of "int" only if they are of different sizes on the machine you're coding on. Period. If a C programmer doesn't understand that, then they have not been adequately trained in the C language and should not use the C language until they have been so trained. From the questions put forth in net.lang.c, it's apparent that the training offered to many C programmers is abysmal. I'm not in the business of training C programmers. I *am*, unfortunately, in the business of fixing the mistakes made by inexpert C programmers. I wish I weren't in that business. Perhaps there should be separate newsgroups for novice and expert C users; however, the difference between the level of expertise exhibited by posters to net.unix and net.unix-wizards has steadily diminished over time. In any case, net.lang.c should *not* be forced to serve as a place where people pick up information that should have been imparted to them when they learned C but wasn't. The proper use of "short", "int", and "long" very definitely falls into "what you should have learned before you started to use C". Unfortunately, a look at the number of programs posted to "net.sources" which have to have "int"s replaced by "long"s before they run on machines other than the VAX for which they were written indicates that far too few people *do* learn the proper use of "short", "int", and "long". If people were as careless at using, say, saws as they were at using the C programming language, the rate at which people lost fingers in their workshops would be a national disgrace. Read some of the postings in the "net.bugs" groups if you don't believe me. A *lot* of those bugs are simply bonehead coding errors; the disgrace is that they come from a system which is shipped and supported by a Large American Corporation. I don't know if other such systems have such a large proportion of bugs caused by stupid errors like not checking whether a pointer is null before using it (I doubt that occurs nearly as much on VMS, because VMS does *not* map location zero into a process' address space), but if they do we have an even bigger problem. Guy Harris
rdp@teddy.UUCP (09/11/85)
In article <2778@sun.uucp> guy@sun.uucp (Guy Harris) writes: >If people were as careless at using, say, saws as they were at using the C >programming language, the rate at which people lost fingers in their >workshops would be a national disgrace. Actually, many people do use saws with the same care that many programmers use C, and the resulting loss-of-digit statistics are, indeed, disgraceful. The exact figures are, however, something I can't immediately put my finger on.
msb@lsuc.UUCP (Mark Brader) (09/13/85)
> > People such as Mr. Harris should be aware that not all people participating > > in this forum are experts. The question was a valid one ... > People who use the C language should be sufficiently expert that they > understand [that material. If not,] then they have not been > adequately trained in the C language and should not use the C language until > they have been so trained. From the questions put forth in net.lang.c, it's > apparent that the training offered to many C programmers is abysmal. I'm > not in the business of training C programmers. I *am*, unfortunately, in > the business of fixing the mistakes made by inexpert C programmers. ... > In any case, net.lang.c should *not* be forced to serve as a place where > people pick up information that should have been imparted to them when they > learned C but wasn't. ... Well, I don't really see why it matters where they learn the stuff, as long as they do learn it. Seems to me that every posting of things that we all ought to know helps to *reduce* the number of those mistakes that Guy is, unfortunately, in the business of fixing. It's easy enough to skip over the messages that are beneath you, if you want. Mark Brader
mojo@kepler.UUCP (Morris Jones) (09/13/85)
Mr. Harris' C snobbery is baloney. I welcome novice questions in net.lang.c.
Feel free to ask them. If nothing else, I'll learn teaching techniques
and examples from the answers.
So pay no attention to that man on his pedestal.
--
Mojo
... Morris Jones, MicroPro Product Development
{dual,hplabs,glacier,lll-crg}!well!micropro!kepler!mojoolson@lasspvax.UUCP (Todd Olson) (09/14/85)
In article <2778@sun.uucp> guy@sun.uucp (Guy Harris) writes: >People who use the C language should be sufficiently expert that they >understand that "long" and "short" should not be selected in favor of "int" I follow you so far ... >only if they are of different sizes on the machine you're coding on. But I can't quite fiqure out what you mean here. Does it mean that is if 'short' 'int' and 'long' are the same size then I should choose something other than 'int'? >Period. If a C programmer doesn't understand that, then they have not been >adequately trained in the C language and should not use the C language until >they have been so trained. > ... >In any case, net.lang.c should *not* be forced to serve as a place where >people pick up information that should have been imparted to them when they >learned C but wasn't. The proper use of "short", "int", and "long" very >definitely falls into "what you should have learned before you started to >use C". > ... > Guy Harris Some of us have not been formally trained to program in C. Some of us, out of curiosity, desire to use something "better" than fortran, or other reason, have taught ourselves C by reading K&R and writing programs. Some of us work in environments where everyone else just wants to get the job done without spending time to aquire more than the minimal skills necessary 'make it run', (even if what they write will be use again, or with some thought could be made to handle a class of (frequently encountered) problems rather than just a special case) and thus have no one to talk these problems over with. Some of us are not able to devote all our time to working with computers because we have other professions. Some of us do not have access to more than one machine and thus, though we'd like to write portably, have know way of experimantally finding out what is and is not portable. Some of us are not system programmers though we are trying to be, on top of our other activities because no one else in our (physics) department is interested in making the machine work. Just that it *@$ better work. None the less we are interested in creating good, well written programs. We are interested in pushing ourselves beyond our previous best to do better this time. Understandable, from your point of view, it is bothersome to have to deal with our mistakes time and again, or to wade through them in the net. If you will occasionally help us (and otherwise ignore us) I will try very hard to think my questions and apparent bugs through before soliciting your aid. One explaination is worth a thousand flames. -- Todd Olson ARPA: olson@lasspvax -- or -- olson%lasspvax@cu-arpa.cs.cornell.edu UUCP: {ihnp4,allegra,...}!cornell!lasspvax!olson US Mail: Dept Physics, Clark Hall, Cornell University, Ithaca, New York 14853
laura@l5.uucp (Laura Creighton) (09/16/85)
In article <792@lsuc.UUCP> msb@lsuc.UUCP (Mark Brader) writes: >Well, I don't really see why it matters where they learn the stuff, >as long as they do learn it. Seems to me that every posting of things >that we all ought to know helps to *reduce* the number of those mistakes >that Guy is, unfortunately, in the business of fixing. > The people who don't know what they are doing and are trying to program in C have a problem, but as long as they know they don't know what they are doing, I am perfectly willing to bear with them. The people who drive me up the wall are the people who post wrong answers to things. Every so often I see somehting posted here which is so off-the-wall that I figure that there must be something to it. After all, nobody could post something so blatantly wrong, could they? There must be something going on here that I don't see, right? When I was at utzoo I went for Henry Spencer's Office. Now that I am consulting to Sun I go to Guy Harris's office. The question is the same. ``Have you read net.lang.c (or net.unix-wizards) today? Is Joe RandomHacker out of his mind?'' The sad thing is that the answer is nearly always ``Yes.'' What I worry about is how many readers of net.lang.c don't know a good answer from a bad one? It is self-evident that a large number of *posters* don't. If the readders are the same way, then how many of them are going to pick up vile, sleazy and incorrect ways of doing things by believing trash that they read here? It is too bad that mod.lang.c didn't fix this problem. -- Laura Creighton (note new address!) sun!l5!laura (that is ell-five, not fifteen) l5!laura@lll-crg.arpa
guy@sun.uucp (Guy Harris) (09/16/85)
> >People who use the C language should be sufficiently expert that they > >understand that "long" and "short" should not be selected in favor of "int" > >only if they are of different sizes on the machine you're coding on. > > But I can't quite fiqure out what you mean here. Does it mean that is > if 'short' 'int' and 'long' are the same size then I should choose > something other than 'int'? You did figure out what I meant - that is exactly what I mean! If you want to have a variable that can hold values outside the range -32767 to 32767, use "long", regardless of whether something else just might happen to work. It won't work on other machines, and unless you can guarantee that the code will *never* be run on another machine, you shouldn't do it. > Some of us have not been formally trained to program in C. > Some of us, out of curiosity, desire to use something "better" than > fortran, or other reason, have taught ourselves C by reading K&R and > writing programs. Too many postings here indicate that the poster skipped the "reading K&R" part or didn't read it very well. > Some of us are not able to devote all our time to working with > computers because we have other professions. Presumably, a physicist building a piece of electronic equipment will have learned enough about electronics not to put 110V across a microprocessor chip. Somebody using C (or any other language) for, say, a program in a physics experiment should have learned enough to know the basics of portability, and of pointer use, and... > Some of us do not have access to more than one machine and thus, though > we'd like to write portably, have know way of experimantally finding out > what is and is not portable. You don't find out what's portable by experimenting. You find out by reading something like Harbison and Steele's "C: A Reference Manual". All experimenting will do is indicate whether something will work on the machines you happen to have at hand. What I'm saying is that some questions - and FAR too many answers - seem to be posted before the poster has checked any references, or read K&R, or otherwise done a bit of legwork themselves. Guy Harris
mikes@3comvax.UUCP (Mike Shannon) (09/16/85)
I don't think it would be a good idea to have two separate groups (one 'expert'
the other 'novice') for C discussions. Personally, I get a lot out of
reading assertions/questions/flames of even novice 'C' programmers (although
I consider myself something of an expert :-)). Even if it's just a matter
of seeing which features of C confuse the newcomers. (this can be helpful
when people come by your office to ask you C questions)
It does get a bit tiresome when people jump in with wrong info or mis-informed
opinions and present them as fact; but I think we all realize that we shouldn't
believe everything we read here. I use this newsgroup as a jumping-off point
for my own explorations of the finer points of C.
Finally, I think it's good that a few authorities (notably Guy Harris) who
actually *do* know what they're talking about are there to keep us on our toes.
(Boy, would I hate to be flamed at by Guy Harris!!!)
offering one man's opinion,
Michael Shannon
p.s. for what it's worth, I've never used a 'short' in my life! :-)
--
Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikesdmh@dicomed.UUCP (Dave Hollander) (09/16/85)
In article <2778@sun.uucp> guy@sun.uucp (Guy Harris) writes: > >People who use the C language should be sufficiently expert that they >understand that "long" and "short" should not be selected in favor of "int" >only if they are of different sizes on the machine you're coding on. >Period. If a C programmer doesn't understand that, then they have not been ... > > Guy Harris Well excuse me! I was trained as a programer in collage ( in Pascal of course) and also by Bell Laboratories but these types of problems are beyond what they saw fit to teach. I will not try to defend the places that offer training, however they do seem to get bogged down by people who do not even understand structures. I have recently returned to the C world (a long and terrible bout of Fortran has ruined many of the good pratices I may of had) I was hoping that this news group would be a good refresher and get me up to date with new ideas. The concept of portability as a science not a black art being one of the ideas. sorry for being so foolish and "boneheaded"! I hope you have to fix one of my broken programs some day! Dave Hollander
rcd@opus.UUCP (Dick Dunn) (09/18/85)
> In article <2778@sun.uucp> guy@sun.uucp (Guy Harris) writes: > >If people were as careless at using, say, saws as they were at using the C > >programming language, the rate at which people lost fingers in their > >workshops would be a national disgrace. > > Actually, many people do use saws with the same care that many programmers > use C, and the resulting loss-of-digit statistics are, indeed, disgraceful. > The exact figures are, however, something I can't immediately put my finger on Ouch! In fact, the issue on the C side (i.e., from California) being integer sizes, I saw (!) that the analogy was rather close: a matter of loss of significant digits as opposed to a significant loss of digits. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Lately it occurs to me what a long, strange trip it's been.
ray@othervax.UUCP (Raymond D. Dunn) (09/18/85)
It is intersting to note in the discussions re short, longs etc. that portability seems to be regarded as a major reason-d'etre for much coding activity. All very well if portability can become ingrained in our way of thinking just as block-structuring has now become (to some), but it should be noted that in this big bad commercial world we (some of us) live in, very few software projects can afford to schedule "extra" time for designing in, and testing, the portability of code. Yes, in the long run, it is maybe worthwhile, but often it falls into the same category as generalising your code as opposed to making it specific - a good thing to do, but often commercially/practically unjustified. On a slightly tangential, but relevant topic (because I'm very intolerant of the intolerance shown on the net (:-): The ability of the "average" programmer, just like the average in any other human endeavour, is often barely capable of producing adequate specific task/specific machine programs, let alone generalised task/generalised machine programs - AND THIS IS THE WORLD WE HAVE TO LIVE IN AND INTERFACE TO. It is not reasonable to hold up an extreme, excellent piece of software and say - "If Joe Foo can write this, why can't you?". You can only expect the maximum that a person is capable of, and motivated to, and help him produce that best. If he cannot absorb/use the information that is presented to him, to its full extent, it need not be either his "fault" or yours! To the people like Guy Harris who get totally p'ed off by the fallability of others, and have the added problem of never being able to resist pointing out the differences in their (perceived) intellects, think of something you know you are not very good at (e.g. carpentry, art, pure theoretical physics etc.) and imagine your interaction with someone who IS good at that, and is trying to get you to produce results. Most people because of their inherant capabilities, must work at a level far below excellence! (At what level do I attempt to work? - the level that **I** regard as excellent - i.e. excellence as defined by me - accepted by some, disagreed with by many!) (:-) (:-) (:-) (:-) (:-) (:-) (:-) (:-) (:-) (:-) (:-) (:-) (:-) (:-) (:-) Smile everyone, I've now got off my high horse - slowly tho' cos my old bones are creaking - follow-ups to net.philosophy! Ray Dunn ..philabs!micomvax!othervax!ray
robert@fortune.UUCP (Robert Clark) (09/20/85)
In article <2803@sun.uucp> (Guy Harris) writes: >> >People who use the C language should be sufficiently expert that they >> >understand that "long" and "short" should not be selected in favor of "int" >> >only if they are of different sizes on the machine you're coding on. >> >> But I can't quite fiqure out what you mean here. Does it mean that is >> if 'short' 'int' and 'long' are the same size then I should choose >> something other than 'int'? > >You did figure out what I meant - that is exactly what I mean! If you want >to have a variable that can hold values outside the range -32767 to 32767, >use "long", regardless of whether something else just might happen to work. >It won't work on other machines, and unless you can guarantee that the code >will *never* be run on another machine, you shouldn't do it. If one is very concerned about portability to other-wordlength machines, why not use typdefs like: typedef int bit16; typedef long bit32; Then make all your declarations as bit16, bit32, etc. Then when you want to port to a machine with 7 bit shorts, 14 bit ints and 35 bit longs :-), just change all the typedefs to "typedef long bit16", etc.... I can see not liking the way this would make the code look, but it would certainly help with portability, and could make a big difference in final process size if there are large arrays, etc. Robert Clark UUCP: {sri-unix, amd, hpda, harpo, ihnp4, allegra}!fortune!robert DDD: (415) 594-2822 USPS: Fortune Systems Corp, 101 Twin Dolphin Pkwy, Redwood Shores, CA 94065
rb@ccivax.UUCP (rex ballard) (09/21/85)
> In article <2778@sun.uucp> guy@sun.uucp (Guy Harris) writes: > >People who use the C language should be sufficiently expert that they > >understand that "long" and "short" should not be selected in favor of "int" > > I follow you so far ... > > >only if they are of different sizes on the machine you're coding on. > > But I can't quite fiqure out what you mean here. Does it mean that is > if 'short' 'int' and 'long' are the same size then I should choose > something other than 'int'? > > >Period. If a C programmer doesn't understand that, then they have not been > >adequately trained in the C language and should not use the C language until > >they have been so trained. Even the "wizards" of C can get 'bit' in unfamiliar situations. A very good example of a case where short than "int" is when communicating binary information between two dissimilar processors. If a 68000 compiler consideres int to be 16 bits, and a 68020 compiler treats it as 32 bits, packed structures had better be very specific. There are cases for it where space (communication time, disk access time, and available storage) may be a deciding factor. Consider the option of sending time samples between two machines at 9600 baud. Perhaps it is time to considere standardizing the size of char, long, and short. At least we should have some small "guarenteed size" of unit like type "byte", which could always be 8 bits unsigned (or signed- vote on it). The Honeywell 6000 uses a 9 bit char, how would you impart packed binary information to it (where every bit is significant)? Speaking of inter-processor communications, how about a binary "packf()/unpackf()" function for the library. It can get real hairy trying to get a complex structure of long words, shorts, and chars between a VAX or PDP-11 and a 68000 in binary form. For that matter letting a 68000 and an 8088 share the same disk can do real strange things to "plot(5)" and similar binary files that write different order & length "ints". It's not always practical to store everything in text.
root@bu-cs.UUCP (Barry Shein) (09/21/85)
>From: ray@othervax.UUCP (Raymond D. Dunn) > >It is intersting to note in the discussions re short, longs etc. that >portability seems to be regarded as a major reason-d'etre for much >coding activity. > >All very well if portability can become ingrained in our way of thinking >just as block-structuring has now become (to some), but it should be noted >that in this big bad commercial world we (some of us) live in, very few >software projects can afford to schedule "extra" time for designing in, and >testing, the portability of code. Yes, in the long run, it is maybe >worthwhile, but often it falls into the same category as generalising your >code as opposed to making it specific - a good thing to do, but often >commercially/practically unjustified. Astounding! I guess you have a right to your opinion, what company do you work for and exactly what processor is your code tied to so I know exactly when to sell short on your stock? DEC-20? IBM7094? Z80? TIMEX/1000? DEC-10? 8008? PDP-8? DG/NOVA? SDS(XDS)? need I go on.... Maybe you should have a little chat with some of the vendors of code for those machines about portability and it's relationship to commercial survival, as the old expression goes, you more likely can't afford *not* to spend the extra time. Sit down and extrapolate the life span of a processor coming to market today (hint: it's shrinking.)* Perhaps more practically, if you can learn to code reasonably portably, you usually can avoid the major pitfalls and fix a piece of code to be actually portable when the need arises without too much trouble (no flames, I know, a 200,000 line system would be better off portable to start, but if it's reasonable it could be fixed *more* easily than re-written.) -Barry Shein, Boston University *exception: ibm370 architecture, give or take XA I assume it will be around forever, tho that still might exclude new markets for your software.
bc@cyb-eng.UUCP (Bill Crews) (09/23/85)
> >From: ray@othervax.UUCP (Raymond D. Dunn) > > > >It is intersting to note in the discussions re short, longs etc. that > >portability seems to be regarded as a major reason-d'etre for much > >coding activity. > > > >All very well if portability can become ingrained in our way of thinking > >just as block-structuring has now become (to some), but it should be noted > >that in this big bad commercial world we (some of us) live in, very few > >software projects can afford to schedule "extra" time for designing in, and > >testing, the portability of code. Yes, in the long run, it is maybe > >worthwhile, but often it falls into the same category as generalising your > >code as opposed to making it specific - a good thing to do, but often > >commercially/practically unjustified. > > Astounding! I guess you have a right to your opinion, what company do > you work for and exactly what processor is your code tied to so I know > exactly when to sell short on your stock? DEC-20? IBM7094? Z80? TIMEX/1000? > DEC-10? 8008? PDP-8? DG/NOVA? SDS(XDS)? need I go on.... > > -Barry Shein, Boston University Once again, another case of a person assuming that everyone's circumstances are the same as his. Some assumptions hurt no one but the assumer until unjustified flames start crossing the net. I am *certainly* not going to take up the case for nonportable coding, but I will *sure* argue that the degree to which portability is a factor in a given development effort is a decision for the development team, not one for Barry Shein, way over there in Boston! -- / \ Bill Crews ( bc ) Cyb Systems, Inc \__/ Austin, Texas [ gatech | ihnp4 | nbires | seismo | ucbvax ] ! ut-sally ! cyb-eng ! bc
ray@othervax.UUCP (Raymond D. Dunn) (09/24/85)
In article <658@bu-cs.UUCP> root@bu-cs.UUCP (Barry Shein) writes: >>From: ray@othervax.UUCP (Raymond D. Dunn) >> >>It is intersting to note in the discussions re short, longs etc. that >>portability seems to be regarded as a major reason-d'etre for much >>coding activity. >>... >> .......... very few >>software projects can afford to schedule "extra" time for designing in, and >>testing, the portability of code..... > >Astounding! .....etc etc. > >.......... Sit down and extrapolate the life span of a processor >coming to market today (hint: it's shrinking.)* > >.... etc. etc. > -Barry Shein, Boston University > Astounding indeed! Its quite amazing how people lead with their jaws! I don't want to comment on the tone of the above flame to my posting, only that: a) There are more things in heaven and earth..... b) The lifespan (thanks for hint) of *products* is such that *every* practical shortcut (commensurate with a professional product) must be taken to ensure the market window is hit. The marketing department waiting to release a product is not going to take a cut in salary while you ensure your program will run on the *next* piece of hardware! Now lets try and keep things in perspective. *Of course* their are various nuances involved here! Aren't there always! Nothing is *ever* black and white! This medium we correspond in has (amongst many others) one major flaw - opinions often come over as extreme (more extreme from some contributors than from others (:-)), because what takes 30 seconds to say, and to moderate, and to give examples of, and exceptions to, takes a bl**dy long time to type, and usually gets distilled down into a few sparse statements. So for crying out load, show some respect for the intelligence/knowledge/ experience of others, even if it differs from your own, and think before you type! (and I include myself as a target of these remarks). Ray Dunn. ..philabs!micomvax!othervax!ray
seifert@hammer.UUCP (Snoopy) (09/25/85)
In article <274@ccivax.UUCP> rb@ccivax.UUCP (rex ballard) writes: >A very good example of a case where short than "int" is when communicating >binary information between two dissimilar processors. If a 68000 compiler >consideres int to be 16 bits, and a 68020 compiler treats it as 32 bits, >packed structures had better be very specific. I've got a very simple solution for this. The prototype works. When I get it polished up to suitable professional standards I'll post it. It's amasing how simple the solution actually is. And thus even more amasing that noone's done it yet. >Perhaps it is time to considere standardizing the size of char, long, and >short. At least we should have some small "guarenteed size" of unit like >type "byte", which could always be 8 bits unsigned (or signed- vote on it). Have fun implementing your 8 bit bytes on machines like the CDC 6x00, which store charactors in 6 bits. (That's right, no lower case! Yucko!) Besides, there are going to be old compilers in use for a long time. Snoopy tektronix!hammer!seifert tektronix!tekecs!doghouse.TEK!snoopy "su" > "Permission Denied"
mikes@3comvax.UUCP (Mike Shannon) (09/26/85)
Ray Dunn writes in the last noted reference: > It is intersting to note in the discussions re short, longs etc. that > portability seems to be regarded as a major reason-d'etre for much > coding activity. > > All very well if portability can become ingrained in our way of thinking > just as block-structuring has now become (to some), but it should be noted > that in this big bad commercial world we (some of us) live in, VERY FEW > SOFTWARE PROJECTS CAN AFFORD TO SCHEDULE "EXTRA" TIME FOR DESIGNING IN, AND > testing, the portability of code. ........ (emphasis is mine) I believe that companies already pay the price for code which is not portable. When I design software, I try to keep things as simple as I can. In order to do this, I try to "abstract out" as many things as possible. This concern for abstraction pays off primarily in reduced design time and increased program reliability. The benefits in maintenance and portability (some programs are never ported) are secondary. I think that people who stress "portability" are actually attempting to say KISS. "Portability" is really not the issue. Abstraction (or "top-down design", or "stepwise refinement" or however you say it) is an inherently worthwhile design practice. -- Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikes
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (09/27/85)
Both portability and abstraction are worthwhile design goals. One can write code using nice data abstraction in Jovial, but this would probably be a mistake. One could write highly portable code that cannot be maintained due to its internal complexity, and this would also be a mistake. "Portability" should be thought of in a fairly broad sense, including "portability to other systems" (traditional meaning) and "portability into the future" (important but often ignored).