Introduction.
	This file keeps all the information related to the different
CHECK-INS done to the "localedef" sources.  Whenever any of the source
files is modified and checked-in, make sure that this file is also
checked-in with appropriate log message.  For example, if the source
file "gen.c" needs a change, then checkout the source file "gen.c" as
well as this file i.e. "maintenance_log".  After done with the changes
to the file "gen.c", provide the details (about the changes made to the
file "gen.c") in the file "maintenance_log" and check-in both these 
files using a single command line. 

08/30/93	
	Checking-in of the source files done which have been modified with 
	minimum change to get "localedef" run on HP-UX 9.0.

	Following two files have been modified for this purpose,

	sem_mthod.c --> Changes related with method loading stuff.
	sem_ctype.c --> To allow successful compilation.

08/30/93
	The CR9050 bug-fixes. 
	Checked in by Sareen on behalf of Alex Leontiev.

	Following two files have been modified,

	gen.c --> 1. Bug fix for proper outputting of era strings.
		  2. Bug fix for proper outputting of alt_digits strings.
		  3. Bug fix for complete handling of nl_langinfo 
		     information.

	gram.y --> Fix for proper handling of alt_digits keyword.	

08/30/93
	The CR9307 bug-fix.
	The CR9307 bug-report says everything about this bug-fix.

	Only one source file has been changed,

	gen.c --> The suggested fix for CR9307 incorporated in it.  
		  This fix was recommended by COSL.  OSF people 
		  have not reverted back yet.

	Comments on the bug-fix.
		The algorithm used by localedef while handling the
	case in which only *toupper* class is specified, had a bug.
	This fix provides the patch to fix that bug.  Following example
	tries to explain the same.

	Let us assume that the *tolower* class is not specified while 
	the *toupper* class is specified as follows,

	toupper  ( <x>, <y> )

	where <x> and <y> are defined in the charmap file as,

	<x>	\x20
	<y>	\x40

	If such is the case then without this bug-fix the towlower(0x40)
	will return 0x40 instead of 0x20.  This will happen for all the
	cases where process code of <x> is smaller than that of <y>.

	This happens because the "for" loop which creates the inverse 
	matrix overrides the already filled location for <y>.  So, our
	fix does not let such a thing happen by checking that we have not
	filled that location already.  Hence with this fix, the towlower(0x40)
	will return 0x20 for the above example.

08/30/93
	Provides the CR9435 Bug Fix.

	Only one file needed code modification,

	sem_xlat.c --> The CR9435 bug-report provides the details.
		       This fix was recommended by COSL.  OSF people 
		       have not reverted back yet.  

08/31/93
	The CR9527 BUG-FIX.

	gen.c --> The details are in the CR9527 bug-report.
		  This fix was recommended by COSL.  OSF people 
		  have not reverted back yet.  

08/31/93
	Some of the minor fixes made to a few more source files got
	left while doing the first checking-in.  This checking-in 
	completes all the changes required to make the localedef compile
	and run on HP-UX 9.0.

	Following files have been changed,

	localedef.c --> The <sys/limits.h> include directive has been changed
			to <limits.h>.
	method.c -->	- do -
	sem_chr.c -->	- do - 
	makefile  -->	Completely changed. 
	scan.c	-->	This has been changed for slightly different reason.
			The PATH_MAX has been redefined as _POSIX_PATH_MAX
			to comply to XPG4.

08/31/93
	Redundant code references removed.
	The CR9522 Bug-Fix.

	Two files were touched,

	sem_chr.c --> The routine sem_set_chr() has been commented out.
	Makefile  --> The reference to "list.c" removed.  The code in this 
		      file is not required.

09/14/93
	This checking in had to be done as a result of leaving a few
	more fixes to make *localedef* sources compile and run on 9.0
	
	Following files have been  touched,

	Makefile     --> By mistake a backslash was left in this file
		         which was removed.
	sem_method.c --> Defining an array got left in the previous
			 checking-in, hence this modification.
	sem_xlat.c   --> Another typing mistake while doing previous 
			 checking-in of this file.

09/14/93  --- sem_coll.c
	The changes made here are to support hexadecimal, octal or decimal
	entries in the collation sequence. localedef did not process entries
	that were not defined in the charmap file. This change removes that
	restriction. Hence, entries of the form "\xd6   \x45;\d65;.." etc are
	now possible.
	Further, a combination of symbols and literals are now made possible.
	All changes made are ifdef'ed with __hpux, and have the comments
	/* HPUX_start_XPG4 ... HPUX_end_XPG4 */

	The routine sem_coll_literal_ref() was modified to define new symbols
	based on the values, if they were not already defined.  The symbol is
	also added to the symbol table.

	The routine sem_collel_list() was modified so that various combination
	of character formats which mean the same character are acceptable.
	for e.g: you may have an entry of the form "<A>  \x41;\101;\d65",
	which essentially means "<A>  <A>;<A>;<A>". 
	This is acceptable, and the check is done against the process code 
	associated with the symbol, instead of the symbol itself.


10/05/93  --- Addition of HP-UX specific functionality
	Incorporated recognition of the following HPUX-specific keywords
	to the grammar: 
		direction, context, alt_punct (LC_CTYPE); 
		alt_digit (LC_NUMERIC);
		year_unit, mon_unit, day_unit, hour_unit, min_unit, sec_unit
			(LC_TIME);

	Note that direction and context used to belong to LC_ALL category 
	(9.0 localedef), but since we no longer have LC_ALL category for 10.0
	these keywords were moved under LC_CTYPE.

	The following files were affectted: gen.c scan.c gram.y

	scan.c was modified to include definition of the new keywords
	(kw_tbl[] array).  gram.y was modified to expect a string operand
	for all these keywords and call sem_set_str() to store the operand
	in the appropriate stuct's.  gen.c was modified such that the new
	fields are output in the .c file for the locale.

	Also, symtab.h was modified to include <osf_hp.h> which contains all
	the missing declarations (e.g., uint) caused by header file
	mismatches.  This is a stopgap fix which should be backed out once we
	consolidate/clean-up our header files.  For 9.0 compilation, the
	missing declaration were handled via a different header file; for
	10.0 the scheme changed which necessitated this change.

	It should also be noted that <sys/localedef.h> and <langinfo.h> were
	modified to take into account the increase in the number of nl_langinfo
	items as the operand to many of the added keywords are HP-UX langinfo 
	items.  <sys/localedef.h> also was modified to add space for storage of 
	operands to the above keywords.  All the additions were made to the
	end of structures. The affected strctures were: _LC_numeric_t, 
	_LC_time_t, and _LC_ctype_t.

	Finally, changes are needed in NLSsetup.c and setlocale.c to ensure
	that these langinfo items are copied during intialization.  That
	work is part of libc and not tracked here.

10/06/93   --- Changes in collation related routines so that charmap files
	can be dispensed with.
	(See also changes made on 09/14/93)

	Changed files: sem_coll.c, gen.c

	Changes were incorporated in the routine sem_coll_literal_ref()
	to allow processing (related to collation) of literals on 09/14/93.
	This allowed the processing of literals in the collation sequence,
	but required atleast one symbol defined in the charmap file, with
	the process code equal to the largest process code used. This was
	required because the collation table was allocated initially with
	this limit (max_wchar_enc).
	The current changes, were made so that this above requirement is no
	longer needed. If the new process code found is larger than
	max_wchar_enc, the table is reallocated. This also means that the
	charmap files are no longer needed for collation processing.
	A related change is made to the routines sem_coll_sym_ref() and
	sem_set_collwgt(), where the symbol's pointer to the collation
	weights (in the collation table) is re-assigned. This is required
	because due to re-allocation, the pointers may have changed.

	The reference to max_wchar_enc in gen.c (collation related) was
	changed to coll->co_wc_max, because this contains the maximum
	value of the collation table. The value max-wchar_enc may be 
	different from this value if CTYPE is processed after LC_COLLATE
	and new characters greater than mx_wchar_enc are encounetered in the
	LC_CTYPE processing. (The CTYPE routines would have changed 
	max_wchar_enc value to reflect this!)

	The other changes made in this check-in are in the routines
	sem_set_collwgt(), sem_set_dflt_collwgt(), sem_collel_list(),
	sem_set_dflt_collwgt_range() and sem_coll_sym_ref().
	These routines have a new symbol type "ST_UNKNOWN", which is
	treated in the same manner as ST_CHR_SYM. This is required because
	the routine  sem_existing_symbol() is due to change so that an
	un-defined symbol will get this new type (ST_UNKNOWN), but the
	processing cannot stop for collation as per XPG4 guidelines.

10/18/93   
	Changes in LC_CTYPE related routines so that undefined symbol and
	hard-coded value specification in the locale definition files can
	be handled as per XPG4 specifications.

	Following files have been changed,

	gen.c	--> Before calling the gen_ctype() routine we temporarily
		    set the 'max_wchar_enc' value to the maximum process
		    code handled during processing the LC_CTYPE class.  We
		    restore the 'max_achar_enc' value after done with the 
		    gen_ctype() routine.  

	localedef.c --> Two global variables are defined and initialized 
		    here for dealing with undefined symbols and hardcoded
		    values.  The 'parsing_loc_def' flag is used to make sure
		    that sanity checks for integral values (non-symbolic) are
		    done while parsing the locale definition file only.  These
		    checks are there for charmap files already.

	sem_chr.c   -->  For undefined symbols and illegal hardcoded values, two
		    defines are used - ST_UNKNOWN (while handling symbol stack)
		    and SK_NONE (while handling semantic stack).  The 
		    sem_exiting_symbol() routine is called to check if the 
		    symbol specified by user in the locale definition file is
		    defined (in the charmap file) or not.  If it is not defined
		    then we set the type to ST_UNKNOWN.

	sem_ctype.c --> If hard-coded values have been defined in any of the 
		    classes of LC_CTYPE category, then a check is required to
		    see if this value exceeds 'max_wchar_enc' or not.  If yes 
		    then reallocation of 'mask' array is required.  A few more
		    data-structures also need to be reset.  This is what this
		    source file has been changed for.

	sem_xlat.c  --> The changesto this source file were required to extend
		    the provision of undefined symbol specification and 
		    hard-coded values specification to "tolower" and "toupper"
		    classes (as these are handled differently from the rest).

	semstack.c  --> A sanity check has been added for hard-coded values
		    specification in locale definition files.  The routine added
		    is 'valid()'.

10/19/93  -- Changes made to fix one of the bugs reported under CR 9053.
	     This fix was made by OSF and I have updated this file based
	     on the updated source (1.3) received from OSF.

	     scan.c -- This file is changed so that it accepts one space or
	     tab as delimiter in the input localedef description file. --
	     (in the collation sequence)
	     eg: <A> <A>;<A> was previously not allowed, there had to be 
	     a minimum of two spaces or tabs.
11/02/93
	Various bug fixes.  Following is the list of all the files which
	have been modified and the details of the modifications.
	
	init.c	--> Instead of initialising the max_wchar_enc with 0,
		it is initialised with 255.  CR9528.

		The various LC_MONETORY and LC_NUMERIC fields are initialised
		with empty strings.  CR9543.

		In case of POSIX, the decimal_point is initialised with "."

	localedef_msg.h
	err.c	--> Two new error messages included.  One of these is for yet
		to be fixed problem (this error will be printed whenever an
		undefined user class gets specified.)

	gen.c	--> An error message is printed if a blank decimal_point is
		specified (or it is not at all specified). CR9543.

	semstack.c
		--> The "valid()" routine is called only if we are dealing with
		"\YYY" types of values in locale definition files.  This is 
		done by using the "value" global variable.  This variable is
		used as a flag. 

	sem_chr.c
		--> During the last bug fix, some of the places in the code
		were left where we were supposed to use (s+1) and not 's'.
		These code places were updated.

		The other modification is for fixing the CR10040.
		The comments in the source file are sufficient to explain
		the significance of this modification.

11/04/93
	Changes for adding the recognition of charclass (XPG4 requirement)
	keyword.  These changes were adopted/merged form the 1.3 update
	from OSF.  The main balk of the changed are in the grammer and
	handling of user-defined classifications.  Since all user-defined
	classifications are specified as a charclass operand, they all
	effectively become predefined. Affected files include:

	err.c	a new message added to handle the case when user-defined
		classifications are present w/o charclass having been
		specified.  Also, some additional changes were merged
		to correct the call to catopen (changed 2nd parameter to 
		NL_CAT_LOCALE).

	init.c	add_predef_classname function was changed from being static
		to allow it to be called from gram.y (y.tab.c).

	scan.c	new keyword and corresponding token added for charclass.

	sem_ctype.c  the code to handle user-defined essentially yanked, since
		they are effectively treated as predefined classifications
		after processing of charclass keyword. Also, next_bit was
		made into a global variabel to allow access from the grammer.

	gram.y	recognigtion of charclass keyword added; the user-defined
		classifications specified for this keyword effectively are
		added to the default predefined classifications (next_bit is
		shifted for each new classification in the grammer).

	Also, I took this opportunity to clean up some compilation warning
	messages caused by having __hpux after #endif (commented out __hpux).
	Changed the declaration of "uint" to "unsigned int" since header files
	setup precluded inclusion of typdef for uint in osf_hp.h (uint is
	defined in sys/type.h in the HPUX_SOURCE name space; but I don't
	want to turn HPUX name space on).

01/03/94
	A lot of changes, mainly for handling of HP15 locales.  HP15 locales
	are processed differently due to the way mbtowc and wcwidth methods
	are designed for these locales. Specifically, mbtowc and wcwidth rely
	on the kanji1 and kanji2 tables; but since these tables are not
	completed yet, we cannot use them in localedef.  Therefore, two
	special built-in methods were created specifically for localedef which
	do not make use of kanji1 and kanji2 tables.  Rather, these simplified
	routines take advantage of the fact that localedef handles one
	character at a time which obviate the need for kanji1 and kanji2
	tables (these tables are mainly used for error checking). The 
	METH_OFFS macro was drastically changed to make use of these built-in
	methods (symtab.h).
	
	Additionally, the way in which method_class is determined is completely
	changed for HPUX.  Since we can have a variety of 2- and 4-byte 
	locales each with their own methods, OSF logic of using mb_cur_max as
	a means of setting method_class won't work (see gram.y).  We had to
	use a combination of mb_cur_max and code_set_name values.  For 
	code_set_name, we require that SJIS and EUC be a substring of the
	code_set_name in the charmap file for these locales.

	Another wide-spread change was to turn on _HPUX_SOURCE before the
	inclusion of localedef.h.  The reason is that a number of data items
	are defined in the _HPUX_SOURCE name space, while localedef is mainly
	XPG4.

01/11/94
	Cleaned up work to allow complete compile and link of locales
	from within localedef:
	pathname.h	changed cc and ld options to conform to HP-UX.
	localedef.c	added code to handle installation of locales
			under /usr/lib/nls/loc/locales; also added a new
			option -n which precludes installation of locales
			under /usr/lib/nls/loc/locales (needed for build of
			standard locales under the BE).
	Note that none of the method libraries are searched by default; 
	hence the build of locales with dependencies on method libraries
	(e.g., HP15 and EUC locales) need to make use of -L option to
	localedef to explicitly specify a search of the appropriate
	method library (see /hpux/shared/supp/usr/src/lib/loc/src/makefile
	for details).

	Also, did some cleanup work for the message catalogs:
	localedef.msg.osf  created and checked in.
	localedef.msg	modified OSF messages were restored, moving the
			original modified messages as new ones to the end
			(per porting guidelines)
	err.c		similar changes to the above for hard-coded default
			messages
	localedef_msg.h added new #defines for the new messages added at the
			end
	gram.y, gen.c   changes for the use of the new constants (above)
			also fixed a bug to terminate processing as soon
			soon as invlaid/missing decimal_point keyword is
			determined (it used to process everything and then
			bail out in gen.c; now it bails out from gram.y).
	
	Modified Makefile to work under BE. Essentially, removed all the 
	temporary paths for -I and -L as all these are now under the
	default directories. The only -L remaining is for methods libraries.

	Added some localization instructions to localedef.msg (need to
	complete this work later).

01/11/94
	Final cleanup of the message catalog, along with localization
	cookbook instructions.  All the C*.src and C*.cm needed for 
	generating various messages were archived into L10N_test_pkg.
	Corrected one message in localedef.c to reference the appropriate
	message number.

01/20/94
	Tentative patch fix for the limitation to the number of character
	classification (LC_CTYPE).  This problem was encountered after the
	latest ja_JP.SJIS.src was checked in.  In this file, ekinsoku and
	bkinsoku were moved to the end of LC_CTYPE category; i.e., after
	first and second classifications.  Although first and second are not
	real character classifications (they're really byte classifications),
	we still process them using the same parsing code used for any other
	character classification.  This means that first and second used to
	get a mask allocated for them. This is not really needed!  Why?
	Because one cannot do a iswctype() on a first/second byte (you need
	to get a process code, but you can't get a process code for a byte).
	We still have a 32 classification limit, but at least the standard
	japanese locales are correct in that ekinsoku/bkinsoku get a proper
	mask.  With this latest fis, users can effectively specify only 1
	character classification of their own (ja_JP.*.src files already
	define 31 classifications)!

	In the process of this fix, added code to at least issue a warnign
	that we have reached the limit (it used to silently shift the next_bit
	mask and eventually getting back to 0 and assigning masks that were
	already in use).

	We can either use "long long" decalration for next_bit mask, and change
	declaration of mask array; or wait till 11.0 when we get 64-bit ints
	(which will expand our current limitation automagically to 64). The
	first solution has some size and performance drawbacks (minor), but
	impact to existing code which may implicitly rely on wctype_t being
	an int is unknown (we'll have to test with a validation run to get
	a better handle).  For now, we'll treat the real fix to increase the
	limitation as an enhancement request.  Janice will ask Japanese
	partners if the limit of 32 is acceptable.

	err.c		Added new warning message (#76) for reaching the
			limit; I also forgotten to add a new message I had
			introduced earlier for temporary file creation failure.

	init.c		Modified add_predef_classname() to check for mask
			being 0, which indicates that we've encountered 32
			classifications and that no more classifications can be
			handled.

	sem_ctype.c	Changed next_bit update such that for first and second
			classfications, they get mask of 0 instead of wasting
			a real mask.

	gram.y		Modified processing of charclass such that next_bit is
			tested for 0 before being left shifted.

	localedef_msg.h Added a new constant for the latest warning message
			added to the message catalog.

	localedef.msg	Added a new warning message.


1/31/94
	Modified the behavior of -P option such that this option no longer
	requires an option-string.  Furthermore, if -P is specified, localedef
	checks for $CC in the environment (getenv("CC")). If $CC is defined,
	it is assumed to contain the complete path to the C compiler, and this
	path will be used to invoke the compiler.  This change was made to
	ensure a better fit w/ our build process.  Larry Lam wanted a way of
	overwriting the default C compiler path (/usr/ccs/bin/cc), since in
	the build environment, the ANSI C compiler is under /opt/ansic/bin/cc.
	Additionally, ld is never moved around in the BE (/usr/ccs/bin/ld).
	Hence, ld invokation should not be affected by -P option (this was the
	case with original OSF code).

	localedef.c	Changes as outlined above.

2/8/94
	Changed the scheme for storage of era and alt_digits:  In each case
	we now store one string which contains all the strings specified in
	the source file, separated by semicolons.  To improve libc performance,
	an additional index array is setup which has the offset into the string
	in the locale for each of the strings in the locale source file. See
	the comments in gen.c for a more complete description of this scheme.
	Also added code for storage of escape character and charmap file 
	pathname.  These are needed by locale(1) for XPG4 conformance.
	Files affectted:

	gen.c	Code generation changes for the new scheme

	gram.y	Code parsing modfied such that era and alt_digits strings
		are stored in a global array of strings, instead of the
		locale object itself.

	init.c  Initialized the additional new fields for escape char and
		charmap file name storage.  Also changed initialization of
		era and alt_digits fields due to storage scheme changed.

	localedef.c  Changes for storage of charmap file name.

	pathname.h   This change should really have gone in with the previous
		check-in for -P option handling.  The default location of the
		ANSI C compiler is different than the default C compiler.

	scan.c	Added code for the storage of escape char in the locale object.


2/16/94
	Added a call to mallopt to turn on fast/small block allocation 
	scheme.  This should improve performance.  Additionally, this masks
	a strange memory fault error which we began experiencing lately, 
	under very specific circumstances:  Only when creating zh_TS.ccdc 
	locale under bourne shell, with -v option and specifying full pathname 
	for all files, including localedef itself.  
	I discivered this during a remake of all locales, using the makefile 
	under $hsl/loc/src.  Since make uses system, which in turn uses 
	/usr/bin/sh (which for is bourne shell for now; later in 10.0 it'll
	be posix shell), I figured how to reproduce the problem (as described
	above).  After long xdb sessions, the best we can tell is that a malloc
	control block is overwritten.  By using the fast/small block allocation
	scheme, we effectively add padding to all allocated memory blocks.
	Without access to memory corruption monitoring tools (e.g., purify)
	in 10.0,  getting to the bttom of this problem is quite hard.  
	Thereofre, Jimmy Lee recommended that we add the mallopt call to
	mask the porblem, and improve our performance at the same time (during
	the debugging session, Jimmy noticed that we had a ton of allocated
	blocks, almost all under 40 bytes in size).  Affected files:

	localedef.c	added mallopt() call

2/17/94
	sem_coll.c	THis source file was modified to take care of
			the case where a hard-coded value is specified
			in the "collating-element" and the process-code
			of this hard-coded file-code is more than that
			of all the file-codes encountered so far.

3/9/94
	Changes for proper handling of multi-weighted collating elements.
	This problem was discovered during validation failure analysis
	of date(1).  The failure was due to a sed(1) misbehavior.  
	Specifically, sed(1) would errouneously treat the space character
	the same as digit (0-9) character for a substitution involving
	ranges.  For exampale 
	echo "ABCD  EFG" | sed -e 's/[0-9][0-9]//'
	would produce  ABCDEFG for all single-byte locales.  The problem
	is actually due to two sources: strcoll and localedef.  The 
	problem in localedef (fixed by this change) was due to improper
	handling of missing explicit weights for multi-weighted elements.
	XPG4 requirs that all the following entries be equivalent when
	two weights are specified in the order_start:
	<A>
	<A>  <A>
	<A>  <A>;<A>

	Existing code was assigning the "undefined" weight to all cases
	where an explicit weight was missing.  Since in all of our standard
	have a two-wight scheme, and for the normal (ASCII) characters the
	second weight was omitted, they all would get the undefined weight.
	In addition, an internal libc routine (_getcolval) is not used 
	properly by strcoll.  Specifically, _getcolval 3rd parameter 
	specifies which weight to use, and existing strcoll uses the last 
	weight for this parameters.  Hence, all normal ASCII characters end
	up collating equally; ergo, the sed misbehavior.  This change
	modifies the erroneous behavior by assigning the last explicit
	weight to all the missing weights.  The libc change will be
	handled separately.  Affected file:

	sem_coll.c

	Changes were made by Ashok, and reviewed and tested by Alex.

03/12/94  sem_coll.c
	Fixed a bug where the weights dont get allocated if there is
	an error return from the routine sem_collel_list() the very first
	time it is called.

03/31/94  sem_coll.c
	Fixed bugs concerned with <UNDEFINED> keyword. (also <HIGH>, <LOW>)
	- localedef fails to handle UNDEFINED keyword if <NUL> has been
	  already defined in the collation order (CR 9357)
	- localedef dumps core if "HIGH" is defined as a collating symbol.
	  (CR 9374)
	- UNDEFINED keyword has a different meaning when weights are specified.
	  (CR 9440)
	(Merged OSF changes into code to fix these bugs).

04/06/94  sem_coll.c
	Fixed CR 9340. Merged OSF changes. Fix for
	localedef dumps core if "collating-element" is declared, but unused.

04/06/94  gen.c
	Fixed the chinese-s locale problem. When LC_COLLATE category is
	missing in the locale definition file, no collation is available
	because of a NULL table. Modified, so that the _C_ table is used.

04/18/94
	XPG4 conformance work:  Added reporting of processed categories to
	stdout, and check for POSIX2_LOCALEDEF via sysconf (the sysconf
	call has to be ifdef'ed so that it is not turned on for use of
	localedef inside the BE; see comments in localedef.c).  Affected
	files are: gram.y, localedef.c, localedef_msg.h, localedef.msg,
	and err.c.

05/05/94
	Changes to sem_coll.c
	(1) Bug fix in sem_collate(). If valid characters are not used
	anywhere in CTYPE of COLLATE category, they do not get "UNDEFINED"
	weights, but are considered as illegal characters (weight 0).

	(2) Changes all over the code marked with the tag /* REGEXP */,
	These changes introduce another "weight" in the collation table
	which contains the "collation order" information. This is the
	order in which the elements appear between order_start and order_end.
	This will be used exclusively by REGEXP libc routines. As a result
	of these changes, the libc collation routines will also be changed -
	to use order-1 weights. The _COLL_WEIGHTS_INLINE definition in
	localedef.h will also be incremented by one. The NLSsetup.c will also
	be changed to include the "order" info for the 'C' locale.

	Changes to gen.c
	Changed gen_collate(), so that the lc_weight_t typedef is the
	complete union. Otherwise the data alignment will be all wrong.

05/06/94
	Changes to sem_coll.c, gen.c
	Added the element co_ord_max to LC_collate_t structure. This was
	required by REGEXP routines.

05/11/94
	DSDe416565 fix:  proper handling of imbeded hex constants in strings
	This defect was discovered by Janice while conducting XPG4 conformance
	testing.  One of the test locales, contained a string of the form
	"d\xe9cmbre" (this is a month name, decmbre, with e being an e with
	the accent mark).  The real_copy_string routine would attempt to
	convert hex constants by passing a pointer from within passed-in
	string to strtoul(3).  However, in the case of "d\xe9cmbre", strtoul
	would convert \xe9c!  Rather than passing a pointer in the middle of
	the passed-in string, we need to copy the appropriate number of
	characters following an escape character (3 characters for decimal
	and octal constant, and 2 for hex, per XPG4) and attempt strtoul()
	conversion on the copied characters only.  Affected modules:

	sem_chr.c:  Changed the logic of real_copy_string function for
                    handling of hard-coded character constants.

	NOTE: I accidentally discovered that if we add copy directives for
	      some of the categories, strings containing hex values get
	      completely mishandled.  I traced this to the setting of
	      copying flag.  The flag setting affects path flow in gen.c,
	      and hex-coded values in strings are completely mishandled.
	      Note that strings are stored properly, it's the outputing
	      of the strings (in gen.c) which is incorrect.  However, 
	      the use of copying flag is rather pervasive, and since XPG4
	      testing does not use this combination, I'm not going to fix
	      this problem now (there are serious bugs with XPG4 testing).
	      We'll have to look into resetting the copying flag when
	      needed.

5/18/94
	Various XPG4 bug fixes reported by Janice:
	DSDe416566: locale source file can be overwritten if locale name
		    matches it; e.g.        localedef -i foo foo.  
		    The fix was to detect this condition after parsing
		    run-string options, and exit with an appropriate error
		    message.  Affected file: localedef.c, err.c, 
		    localedef.msg, and localedef_msg.h.

	DSDe416567: Incorrect default YESEXPR/NOEXPR values.
		    If no LC_MESSAGE category is specified, the default value
		    for YESEXPR/NOEXPR used to be "[yY][[:alpha:]]*" and
		    "[nN][[:alpha:]]*", respectively.  Changed these to 
		    conform to XPG4 ("^[yY]" and "^[nN]").  Files affected:
		    init.c.

05/19/94	sem_coll.c gen.c
		These are the REGEXP related changes. See 05/05/94 changes.
		These changes ensure that the UNDEFINED elements get their
		"collation order" based on the filecode rather than their
		process codes. i.e., it is sorted based on filecode values.

06/13/94	More XPG4 related changes
		/usr/include/ctype.h was changed to meet XPG4 compliance
		requirment.  As a result, all _IS* (e.g., _ISCNTRL) constants
		were moved form _XOPEN_SOURCE to _HPUX_SOURCE name-space.
		So for the following files, bracketed the inclusion of
		ctyp.h by a pair of #define _INCLUDE_HPUX_SOURCE and 
		#undefine _INCLUDE_HPUX_SOURCE:  check.c, init.c, sem_ctype.c 
		and sem_xlat.c.  These changes were identified during build 
		testing with the new compatibility libc (but according to Jim, 
		we would have seen these problems later anyway).

06/14/94	Compatiblity/re-engineered libc changes
		Changed gen.c such that langinfo items appear in the same 
		order as they do in 9.0.  This is so that we can share
		langinfo.h between 9.0 and 10.0.  This was done per Janice's
		request in her work to consolidate 9.0 and 10.0 setlocale 
		into one call in 10.0 (the changes were made and tested 
		around 5/25, but didn't get checked in for a while).  

		NOTE: Changes were not ifdef'ed as this would really clutter 
		the source (there were already ifdefs present in the part of
		the code I changed).

NOTE:  Some intermediate check-ins were not logged in this file since changes
       were fairly small, self-evident, and commented in source.

07/07/94	locale what strings (DSDe418237 fix):
		Needed to add a what string to the locales so that we could
		easily check for mismatch between locales and the system.  The
		easiest (and most reliable) is to actually include hpux_rel.c
		in gen.c, and then output HPUX_ID (which is declared in 
		hpux_rel.c) as part of the locale .c file.  Note that any
		other means (e.g., doing a popen(3) inside localedef itself
		and dynamically doing a "what /usr/bin/localedef" won't work
		since in the BE, the localedef used to build standard locales
		is NOT under /usr/bin).  
		
		Affectted files:  gen.c

08/15/94	Usability improvement (DSDe419041 fix):
		Changed the way the link command is created so that users don't
		have to explicitly specify the standard methods libraries.
		This is useful for those who whish to make minor tweaks to our
		standard multibyte locales w/o modifying the methods (e.g., add
		new file codes (valid in our range); change character classifi-
		cations). Without this change, creating a new locale w/ minor
		tweaks is tricky in that the user needs to know which methods
		library to specify to be passed to the linker via the -L option 
		(for example, to recreate the japanese locale, user will have 
		 to add 
			-L "-L/usr/lib/nls/loc/methods -lSJIS"
		to the localedef invokation; otherwise, the resultant locale
		will be unusable since it'll contain a lot of unsat code and 
		shl_load() (in setlocale()) of this locale will fail; and the 
		user will have no clue where to begin).

		The fix was to use the information we have in std_methods_tbl 
		array.  The two pieces of info needed are the library to be 
		searched (argument to -l option of ld) and the path to this 
		library (the argument for the -L option of ld).  The library 
		name was already there (it's lib_name field of method_t type).
		For the library path, instead of introducing a new field to 
		method_t, I borrowed an unused field, package (we don't have 
		the concept of a library package on HP-UX).  Thus, localedef 
		can now automatically decide which library to search and where 
		that library is, for the standard locales.  This decision is 
		simply keyed off of the method_class global (index into the 
		std_methods_tbl).  The code to do this looks a bit more 
		complicated since I wanted to make sure we don't search libc 
		twice (better performance). 

		This change also meant that the make file for creating standard
		locales ($hsl/loc/src/makefile) got simpler for the multibyte 
		locales (no need for -L "-L/usr/lib/nls/loc/methods.1 -l....").
		This change was also checked in.


09/07/94	DSDe419041 fix (continued):
		Discovered that the previous changes for usability improvment, 
		broke the user-defined methods specification methodology.
		Whereas we used to have entries like the following in the .m
		file:
			method  method_addr  ""  full_library_path

		we now have to specify:
			method  method_addr  library_path  library_name

		This is all due to the redifinition of the package field of
		method_t structure, and the way library names are specified.
		For example, if a custom mblen() method called my_mblen is to 
		be used, and this method is in libmy_methods.sl, which is under
		/users/my_home/methods directory, then the entry for specifying
		the use of this method in the .m file is:
			mblen "my_mblen" "/users/my_home/methods" "my_methods"

		localedef will invoke ld(1) with the following additional
		parameters:
			-L /users/my_home/methods -lmy_methods
		
		The reson this slipped trough the testing for the previous
		check-in is that we don't have tests for customized methods
		via the use of -m options.  Will need to add this to the test
		suite at a later time (have to think out carefully how to test
		for this).


09/19/94	DSDe420361 fix:
		Corrected the usage of catopen(3) calls in err.c such that
		localedef can be properly localized.  There were two problems
		with the existing catopen(3) calls:

		1. They all specified "localedef.cat" as the first parameter
		   (this should be "localedef")

		2. They all had NL_CAT_LOCALE as the second parameter; however,
		   since localedef does not normally call setlocale(3), the
		   use of NL_CAT_LOCALE will cause an error (see 10.0 catopen
		   manpage).  Changed this to 0, which is essentially XPG3
		   behavior; i.e., LANG determines what message catalog to
		   open (NL_CAT_LOCALE specifies that LC_MESSAGES be used in
		   determining which message catalog to open, after a 
		   successful setlocale call).

		Additionally, added the following line to localedef.msg:
		#quote "
		This will cause no extraneous quotation marks being displayed
		in the output for localized message catalogs.


12/19/94	DSDe419823 fix:
		Removed dependency of localedef upon the various methods
		libraries under /usr/lib/nls/loc/methods/*.sl. Due to this
		problem, in 10.0 we had to ship all the methods libraries
		on all the bundled HP-UX systems.  This problem was caused
		by hard-coded function entry points of all different methods 
		(SJIS, HP15 and various EUCs) ih the std_methods array. Since 
		localedef needs to have access to only one set of methds (one
		method class at a time), a simple fix is to make use of dynamic 
		loading to map in the needed methods at run time.  The fix
		is rather small: removed hard-coded function enty points and
		added a routine to map in the required methods (the ones that
		localedef uses).  Impacted files are:

		sem_method.c  Added a new function, load_std_methods(), to call
			the load_method() routine to map in the methods which
			localedef itself calls (mbtowc(), wcwidth(), and 
			wctomb()). NOTE: If localedef needs to call any other
			methods, additional load_method() calls need to be 
			added to this routine.

		method.c   Removed all function entry points for SJIS, eucJP,
			eucTW, and HP15 methods by setting them to the 0
			(effectively NULL pointer).

		gram.y     Enhanced the grammer to call load_std_methods()
			as soon as the method class is determined.

06/15/95	cswidth enhancement 

	* The localedef grammar has been modified to include the new
	  definition,
	    "<cswidth> text"

	*  The "/usr/include/localedef.h" was modified to add a new
	   field to the _LC_charmap_t structure.  The new field being
		char     *cm_cswidth;       /* cswidth parameter  */

	*  The gen.c source was modified to generate _LC_charmap_t
	   structure with the new field.

	*  On the libc side, the NLSsetup.c code was modified so that
	   nl_langinfo(CSWIDTH) will return the cswidth parameter.
	   (This will be used by the eucset(1) and locale(1) command to
	   get the cswidth parameter).  The __charmap_init() function
	   was modified.

	*  The locale(1) command also has been updated to report the
	   cswidth parameter.


	Impacted files:
	--------------
	gen.c:  The gen_charmap() and gen_locale() functions were
		modified to handle the new cm_cswidh element in the
		__LC_charmap_t structure.

	gram.y: The grammar was modified to recognize the "<cswidth>"
		definition and to detect whether LC_COLLATE section is
		specified in the description file. If it is not there,
		the dummy_collate() function is called.

	init.c,scan.c:  The new symbol "<cswidth>" is initialized in the
		symbol table and it is added to the static table
		kw_tbl[];

	err.c, localedef.msg:  A new error message is added for the
		<cswidth> argument.
