scan.h #1

  • //
  • guest/
  • perforce_software/
  • jam/
  • src/
  • scan.h
  • View
  • Commits
  • Open Download .zip Download (1 KB)
/*
 * 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