bill@hao.ucar.edu (Bill Roberts) (02/12/88)
I have a number of questions which I hope folks out yonder can shine some light
on:
1) I'm trying to port over to the Mac, from a UNIX system (4.3bsd) a relatively
simple C program. The program creates a linked list to store data read from
a file. Part of these data contain coordinates. I go down the list, extracting
the coordinates and convert these to integers, which I then use as indices into
an array whos element would be a pointer to the corresponding node in the list.
I then want to use the indices of this array to represent the local coordinates
of a window. The problem is that the Mac apparently cannot handle any single
segment larger than 32K and my array of pointers, for a window that is 250 X 250pixels, is much larger than 32K (62500 to be exact.)
2) Also, I have a line in the code like:
stuff...
while (sptr->next != NULL){
...
do some stuff;
};
more stuff...
LSC acts as though it doesn't recognize the NULL (0L). Is it the case that I
have to explicitly set the last node's next pointer to 0L?
3) Also, why doesn't scanf() echo characters while operating in the "console"
window?
Thanks in advance for any information on these issues.
--Bill
UUCP: {hplabs, seismo, nbires, noao}!hao!bill
CSNET: bill@ncar.csnet
ARPA: bill%ncar@CSNET-RELAY.ARPA
INTERNET: bill@hao.ucar.edu
"... the Eagle Wing palace of the Queen Chinee'"km@cadre.dsl.PITTSBURGH.EDU (Ken Mitchum) (02/12/88)
In article <1161@hao.ucar.edu> bill@hao.ucar.edu (Bill Roberts) writes: >segment larger than 32K and my array of pointers, for a window that is 250 X 250pixels, is much larger than 32K (62500 to be exact.) You can allocate space for a larger array, but you must do at at runtime, using malloc() or other allocation functions. The total static variable space cannot exceed 32K. This is a Mac limitation, not one of LSC. >LSC acts as though it doesn't recognize the NULL (0L). Is it the case that I >have to explicitly set the last node's next pointer to 0L? If the node was allocated statically, the fields should be set to zero. If it was allocated on the stack, or through a call such as malloc(), it will contain garbage. Try calloc(), or set the field yourself.
rs4u+@andrew.cmu.edu (Richard Siegel) (02/12/88)
1) It's not possible to have a static data structure bigger than 32K in
size. You may want to consider a more dynamic structure than a two-dimension
al array.
2) That's exactly the case. Since variables aren't automatically initialized,
you need to set the next field to be nil, otherwise your loop won't know
when to terminate.
3) there's a bug in scanf(). The quickie workaround is to use gets(), and
then sscanf() to parse the input. It's an extra step, but it does seem to
work.
--Rich
===================================================================
Richard Siegel
THINK Technologies, QA Technician (on leave)
The opinions stated here do not represent the policies
of THINK Technologies or of Carnegie-Mellon University.
Arpa: rs4u@andrew.cmu.edu
UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rs4u
==================================================================zrm@eddie.MIT.EDU (Zigurd R. Mednieks) (02/12/88)
In article <981@cadre.dsl.PITTSBURGH.EDU> km@cadre.dsl.pittsburgh.edu.UUCP (Ken Mitchum) writes: >In article <1161@hao.ucar.edu> bill@hao.ucar.edu (Bill Roberts) writes: > >it was allocated on the stack, or through a call such as malloc(), it will >contain garbage. Try calloc(), or set the field yourself. Fer gosh sakes, use the Mac Toolbox memory managment. Especially if you are managing big chunks of memory, and have dynamic requirements through the course of running the program. The Mac Memory Manager has far more powerful and efficient ways of handling memory allocation and compaction than the standard Unix library has. Another reason for using the Toolbox is reliability. Through version 2.13 of LSC there had been a major brain bubble in the Unix compatible realloc function. It seems that compared to the very high reliability of the rest of the product, the Unix compatibity libraries are a weak point. Furthermore, since the Toolbox is the same everywhere, and the Unix libraries are implemented separately in every Mac development environment that has them, you are better off sticking to the Toolbox if you ever change your mind about compilers (or languages, for that matter). -Zigurd -- ------------------------------------------------------------------------ Zigurd Mednieks MURSU Corporation (617)424-0146 25 Exeter Street Boston, MA 02116
edmoy@violet.berkeley.edu (;;;;YF37) (02/13/88)
In article <1161@hao.ucar.edu> bill@hao.ucar.edu (Bill Roberts) writes: >I have a number of questions which I hope folks out yonder can shine some light >on: >1) I'm trying to port over to the Mac, from a UNIX system (4.3bsd) a relatively >simple C program... >The problem is that the Mac apparently cannot handle any single >segment larger than 32K and my array of pointers, for a window that is >250 X 250pixels, is much larger than 32K (62500 to be exact.) Allocate the array at run time, using NewHandle() or NewPtr(). The size argument to both of these is a long. >2) Also, I have a line in the code like: > > stuff... > > while (sptr->next != NULL){ > ... > do some stuff; > }; > more stuff... >LSC acts as though it doesn't recognize the NULL (0L). Is it the case that I >have to explicitly set the last node's next pointer to 0L? If you are using malloc() to create the nodes, then it is not guaranteed that the structure will contain all zeros. Use calloc() to get a zero-filled structure. Even so, it is still good programming practice to assign all used structure elements to initial values (like NULL in this case). Edward Moy Workstation Software Support Group University of California Berkeley, CA 94720 edmoy@violet.Berkeley.EDU ucbvax!violet!edmoy
smethers@psu-cs.UUCP (Paul Smethers) (02/21/88)
In article <8158@eddie.MIT.EDU> zrm@eddie.MIT.EDU (Zigurd R. Mednieks) writes: > >Fer gosh sakes, use the Mac Toolbox memory managment. Especially if >you are managing big chunks of memory, and have dynamic requirements >through the course of running the program. The Mac Memory Manager has >far more powerful and efficient ways of handling memory allocation and >compaction than the standard Unix library has. I agree that the Mac Memory Manager is probably the best way to go when implementing programs on the Macintosh, but by using it you restrict your portability to other machines. Even if I never plan on porting an application, I am always very weary of writing code that may later restrict it. If you don't think that malloc is done right, then use macros that hide what you are doing, and redefine the macros on other computers. >................. Furthermore, since the Toolbox is the same >everywhere, and the Unix libraries are implemented separately in every >Mac development environment that has them, you are better off sticking >to the Toolbox if you ever change your mind about compilers (or >languages, for that matter). Again, you are making the assumption that a program will never work on a unix windowing system (such as a Sun), or an IBM. All computers are now converging to windowing systems, and even though you write for the Mac now, you never know when you need the portability. The windowing portability is not a easy problem, but the memory portability is almost free because of the standards with unix libraries (malloc type routines). The same goes for file i/o (printf). One of the reasons we write in 'C' instead of Assembly is because we want portability that Assembly doesn't give us (sure there are other reasons, but this is one of them). Pascal has too many extensions and dialects, but K&R 'C' is pretty portable if you follow good coding practices. Paul Smethers SmethersBarnes
zrm@eddie.MIT.EDU (Zigurd R. Mednieks) (02/23/88)
In article <501@psu-cs.UUCP> smethers@psu-cs.UUCP (Paul Smethers) writes: >I agree that the Mac Memory Manager is probably the best way to go when >implementing programs on the Macintosh, but by using it you restrict your >portability to other machines... In the specific case of the Macintosh Toolbox Memory Manager I would choose the strategy of implementing compatible memory management on a porting target. For other parts of a program, like its on-disk document structure, I would make it exactly the same on all machines. > ... All computers are now >converging to windowing systems, and even though you write for the Mac >now, you never know when you need the portability. The windowing portability >is not a easy problem, but the memory portability is almost free because >of the standards with unix libraries (malloc type routines). The same >goes for file i/o (printf). You bet windowing isn't easy to make portable. I believe the best you can do at this point is make a program structure that can be implemented in several window systems. For instance, in many applications it makes sense to think of each window as a view on the data. Porting involves implementing the views in a different windowing and graphics environment. I would not rely on malloc, the printf/scanf function, and least of all, fread/fwrite to enhance portability. In the Macintosh environment they just add bulk to the program without yielding benefits above the availble Toolbox calls. In Unix environments, printf is growing irrelevent in the face of much more powerful Postscript-based formatting. (For instance, dialog boxes programmed to substitute strings at the client end of a session.) Hoping to design for easy portability is a grail quest. And Murphy's law dictates that once easy portability is attained, the program (and likely its implementation language as well) will be obsolete. Software is so perishable it can hardly be called an asset. The best that can be hoped for is that algorthims, techniques, and the engineering talent that makes programs can be preserved from one product generation to the next. -Zigurd -- ------------------------------------------------------------------------ Zigurd Mednieks MURSU Corporation (617)424-0146 25 Exeter Street Boston, MA 02116