rev 1.27 ("iso8601" option keyword) revs 1.12/1.10/1.5/1.4 ($CVSHeader$
support) rev 1.2 ($CVS_LOCAL_BRANCH_NUM support for local commit
feature of cvsup) into version 1.11.22.
Note rev 1.21 ("-D date" checkout bug relating to 1.1.1.1 vs 1.1
revisions), rev 1.13 (allow -D'date' with -r'branch' on a checkout),
rev 1.6 (use xstrdup rather than strdup) are fixed in the vendor sources
rev 1.17 (environtmental var "CVS_OPTIONS"), rev 1.14 ('-g' option to
support shared-group access), rev 1.7 ('-R' read-only repository mode),
rev 1.6 (support for checking out from a read-only repository),
revs 1.4 & 1.5 ("tagexpand=") into version 1.11.22.
Merge rev 1.14: comprehensive -T CVS/Template support, rev 1.9: new long
flag that causes cvs to ignore the CVSROOT/passwd file, rev 1.3: support
for checking out from a read-only repository, rev. 1.2: support for local
$Id$ keyword into cvs 1.11.22.
Note that rev 1.4 (make verifymsg extra useful) is OBE.
rev 1.4: flip the default for CVS_RSH to "ssh", rev 1.2: fix a problem
sometimes seen when doing checkouts from a local repo and committing
via remote cvs (a cvs -d override of the mismatched CVS/Root files was
missing) into cvs 1.11.22.
cplus_demangle_type. This is the rev 1.50-1.51 change.
Our addr2line, etc.. would crash if used on C++ code that contains
certain symbol types. One example is
_ZN13PatternDriver23StringScalarDeleteValueC1ERKNS_25ConflateStringScalarValueERKNS_25AbstractStringScalarValueERKNS_12TemplateEnumINS_12pdcomplementELZNS_16complement_namesEELZNS_14COMPLEMENTENUMEEEE
CVSROOT/config file options that control keyword expansion. cvs-1.12 has
its own $Id$ expansion controls and they're configured in CVSROOT/config
rather than CVSROOT/options. The problem is that current cvs-1.11.x
doesn't understand the future keywords.....
Add trivial forward support for the new keywords for when cvs-1.12
hits the tree down the road. CVSROOT/options won't be going away - cvsup
uses it.
says they are never supposed to, and the fact that they did could
cause apps that run with unmasked FP exceptions to SIGFPE after a
scanf() or strtod(). The vendor stated that he will not be fixing
this, citing portability concerns.
- Accept the '0x' prefix so strtod("nan(0x...)", NULL) returns the same
thing as gcc's builtin nan("0x...") for such strings.
- Don't return uninitialized memory.
- Finish processing the string up to the closing ')' (provided it's
lexically valid) for compatibility with C99 and *scanf().
