/* * Copyright 1993, 1995 Christopher Seiwald. * * This file is part of Jam - see jam.c for Copyright information. */ /* * scan.h - the jam yacc scanner * * External functions: * * yyerror( char *s ) - print a parsing error message * yyfparse( char *s ) - scan include file s * yylex() - parse the next token, returning its type * yymode() - adjust lexicon of scanner * yyparse() - declaration for yacc parser * yyanyerrors() - indicate if any parsing errors occured * * The yymode() function is for the parser to adjust the lexicon of the * scanner. Aside from normal keyword scanning, there is a mode to * handle action strings (look only for the closing }) and a mode to * ignore most keywords when looking for a punctuation keyword. This * allows non-punctuation keywords to be used in lists without quoting. */ /* * YYSTYPE - value of a lexical token */ # define YYSTYPE YYSYMBOL typedef struct _YYSTYPE { int type; char *string; PARSE *parse; LIST *list; int number; } YYSTYPE; extern YYSTYPE yylval; void yyerror(); void yyfparse(); int yylex(); void yymode(); int yyparse(); int yyanyerrors(); # define SCAN_NORMAL 0 /* normal parsing */ # define SCAN_STRING 1 /* look only for matching } */ # define SCAN_PUNCT 2 /* only punctuation keywords */
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#6 | 9904 | tony |
Port 2008.1 P4 to MVS Unix System Services. This is an onsite port carried out at Bank of America in Croydon. It's not pretty. There are some uglies in here which could probably be taken care of in better ways, but I was pressed for time. Here's the background to each of the issues I found: 1. The compiler really didn't like our Zeroconf code, and since building Avahi on the mainframe wasn't top of my agenda, I disabled it with some heinous ifdef's in client.cc. Sorry. The compiler was bitching about types of arguments being passed to zeroconf methods, and it wasn't obvious to me what the problem was either. I think we could use a -DUSE_ZEROCONF in our Jamrules for occasions like this; that would be cleaner than a platform ifdef in client.cc. With more time, it might be possible to make the zeroconf code compile on MVS, but getting dynamic loading working on that platform is ambitious I think. 2. The mapping code needed ifdefs too (again, sorry!). On MVS, C and C++ don't share the same linkage and qsort() is a C function so it (apparently) can't take a pointer to a C++ function. So, all the qsort() compare functions have to be declared as 'extern "C"'. See: http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.bpxbd00/qsort.htm I didn't ifdef these as I don't think they'll do any harm on other platforms. 3. support/random.cc needed an ifdef (no big deal) 4. sys/netaddr.cc had to have a (correct) const removed since the MVS implementation of inet_addr takes a 'char *' argument instead of 'const char *'. I ifdef'd that to keep it clean on other platforms. 5. zlib/zconf.h had some old pragmas that no longer apply. 6. Jamrules: I reinstated the old rules from MVS builds, and made EBCDIC optional rather than compulsory. I also documented in it the environment variables we set to persuade the compilers on BofA's machine to behave. These may, or may not be required on other MVS boxes. No idea. Building Jam also had a few idiosyncracies: 1. Best to assume the yacc on MVS is broken. It was there, but not in great shape. I disabled it in Jambase and I think that's a sensible thing to do going forward. 2. yylineno() can't return a 'const int' on MVS. Not sure why it's defined that way on other platforms so I changed it to just returning an int. Hopefully that won't break elsewhere... There are three binaries being submitted here: jam - built from main bin.mvs/p4 - EBCDIC client bin.mvs/ascii/p4 - Non-EBCDIC client The ascii client identifies itself as such: P4/MVS/2008.1.ascii/164042 While unconventional, I thought that was the best plan so that if we take support calls on it, we'll get a clue. p4transfer.py: Transferred from production |
||
#5 | 9903 | Perforce staff |
Jam -dr now reports file/line numbers, at no small effort. New functionality documented in RELNOTES. p4transfer.py: Transferred from production |
||
#4 | 2493 | rmg |
Rewrite the past: update all jam's source with comments to reflect changes since about 2.3, very early 2001. Whitespace only change. === computer:1666: Change 37660 by seiwald@play-seiwald on 2002/11/06 22:41:35 Note: I regenerated jamgram.c on my linux 7.3 system prior to the submit, since patch was so unhappy trying to lay down the changes from Christopher's change. Presumably this is just due to different yacc/bison/whatever particulars on the system where Christopher made the changes originally. - rmg |
||
#3 | 2491 | rmg |
Some consting in jam to make it more compilable by C++ compilers. No functional change. === computer:1666: Change 37433 by perforce@perforce on 2002/10/30 16:08:51 Recreational const-ing of jam, for compilers that don't allow "string" to be passed as a non-const char *. This included a few places where we were modifying what could possibly have been read-only storage, oddly enough. No functional change. === computer:1666: Change 37602 by seiwald@play-seiwald on 2002/11/04 17:25:40 |
||
#2 | 486 | Perforce staff |
Jam 2.3. See RELNOTES for a list of changes from 2.2.x. Just about every source file was touched when jam got ANSI-fied. |
||
#1 | 2 | laura | Add Jam/MR 2.2 source |