jkjl@munmurra.mu.oz (John Lim) (05/24/89)
I'm been busy porting the some GNU C code to the mac. Here's a little hint if you use Bison and Flex with LSC like i do. Bison and Flex were compiled using MPW C which maps '\n' to carraige return, not linefeed. LSC maps '\n' to linefeed as in UNIX. But the symbol tables in both Bison and Flex expect '\n' defined in your .y and .l files to be carraige returns. It took me 4 stupid hours of debugging to realize this ( I dont own MPW C, just TML Pascal //). What this means when porting such code to LSC, use 1. The "b" flag for reading files (binary mode). 2. Change all instances of '\n' in the .c generated files to '\r' (and the .h files too !). 3. insert the line in the *.tab.c files: #define bcopy(x,y,z) BlockMove(x,y,z) 4. Rewrite alloca() or if you have lots of memory ... #define alloca(x) mlalloc((long) (x)) /* mem not freed */ Alternatively, rewrite the stdio project to make '\r' and '\n' equivalent B-). john lim
earleh@eleazar.dartmouth.edu (Earle R. Horton) (05/24/89)
In article <1133@munmurra.mu.oz> jkjl@munmurra.mu.oz (John Lim) writes: >I'm been busy porting the some GNU C code to the mac. Here's a little >hint if you use Bison and Flex with LSC like i do. Bison and Flex were >compiled using MPW C which maps '\n' to carraige return, not linefeed. > >LSC maps '\n' to linefeed as in UNIX. But the symbol tables in both >Bison and Flex expect '\n' defined in your .y and .l files to be >carraige returns. It took me 4 stupid hours of debugging to realize this >( I dont own MPW C, just TML Pascal //). > The latest edit of flex writes out two character tables: one for ('\n' == 10) and another for ('\n' == 13). A preprocessor macro is used to decide, at the time of compilation of the flex-produced C-code, what the end-of-line character will be. This means that the output C-code can be used directly with LSC, MPW C, or with your favorite MSDOS C compiler. The program is on sumex. If you don't have internet ftp, you can get it from me by sending a pre-formatted 800k disk, mailer, and return postage to the address at the end of this article. Other goodies will be included, up to disk capacity. If you're porting GNU or another PD code to the Mac, by all means include some on the disk! >What this means when porting such code to LSC, use > >1. The "b" flag for reading files (binary mode). > >2. Change all instances of '\n' in the .c generated files to '\r' > (and the .h files too !). > No longer necessary if you get the new edit of flex. All instances of '\n' have been replaced with EOLCHAR, and you control what this means. Make sure that your choice of EOLCHAR agrees with your choice whether or not to use binary mode, however! >3. insert the line in the *.tab.c files: > #define bcopy(x,y,z) BlockMove(x,y,z) > If you put this in your "bison.simple" file, then you only have to do it once. >4. Rewrite alloca() or if you have lots of memory ... > #define alloca(x) mlalloc((long) (x)) /* mem not freed */ A better solution is to write your own "yyoverflow()" routine. Look at the "bison.simple" file to see how this might be done. A problem exists with assembler versions of alloca() that make space on the stack frame of the caller. Sometimes these are incompatible with the C compiler's handling of the stack. You have to look at the assembler- (or disassembled machine-) code produced by the function which calls alloca() for potential problems. If you are not reasonably proficient in assembler, you might not be able to figure out whether you have the proper alloca() for use with your compiler. I did the flex port to the Mac. I supplied the alloca() that comes with it. I don't have any idea whether a direct translation of this routine to LSC will be safe to use. Earle R. Horton 23 Fletcher Circle # No stamps -> You don't get your disk back. Hanover, NH 03755 "People forget how fast you did a job, but they remember how well you did it." Salada Tag Lines
MAC.ROMOS@applelink.apple.com (Ian Hendry) (05/26/89)
In article <13619@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > Other goodies will be included, up to disk capacity. > If you're porting GNU or another PD code to the Mac, by all means > include some on the disk! Not to nit picks but I thought that GNU code was NOT public domain. I was reading something about the various GNU projects and the impression I got was that GNU code has a license. If I remember correctly, the license does not limit distribution but it does require that source code be distibuted with any GNU product and that GNU code never be used in a comercial package. This is very different from public domain (with which you can do anything you want). You do not have a license to release software using GNU code into the public domain the author of the GNU code (which escapes me...??Freesoft Foundation?? ??Richard S??). I hope that this does not come across as "Young Proto-Lawyer Zealot from Hell vs. Earle 'so-string-me-up-for-not-knowing-everything' Horton". It is not intended that way. Well, that said, I suppose I ought to sit back and wait for the flames and corrections. Ian Hendry MAC.ROMOS@applelink.apple.com Make sure my name is in the subject of any Email, or post replies to network. TE: 408-974-4737 Disclaimer: It was all HIS idea anyway! Nothing I say reflects anything my employer means... or anything I mean for that matter.