blob: 57fa3d1df47a7589a90f884adcf8178eb6077b2b [file] [log] [blame]
xdc-H08 (corevers:; B:200,G:200,R:200)
eXpanDed C Tools (XDCtools)
This tree contains the RTSC build and configuration engines for
target content. The tree is used in XDCtools 3.60 product releases where
we implemented some changes that allow for smaller config C files.
Librarian repo creation
The xdc.git repo was created to "track" the repo maintained at and was created as follows:
git clone --bare ssh:// xdc.git
cd xdc.git
git config remote.origin.fetch "+refs/heads/*:refs/heads/*"
o setup ssh to enable "git" from xlibrary as "dr" (if necessary)
cd ~xlibrary/.ssh
cp -f config-dr config
o fetch the latest changes from the Eclipse git server
cd xdc.git
git fetch
o Build this tree from Linux using standard SM-MAKE
# clone the tree and merge/review user content
ggentree -u xdc.git/
cd xdc-H??
# unzip from the last released tree
unzip ../xdc-H??/
# make sure the user email and name are your eclipse credentials
git merge origin/xdccore-H-dr
# build the tree on Linux
SM-MAKE .clean
SM-MAKE .all-files >& Make.log
# update README
emacs README
git commit -a -m xdc-H??
# release the tree
greltree -m "something brief and meaningful"
o to build only packages in src/packages from scratch:
SM-MAKE .xdc-packages
o to build bundles:
SM-MAKE .bundles
xdc.runtime for '$S' conversion doPrint() calls printfExtend(), which then
calls doPrint() again. The return value for doPrint() was the
number of characters that would be printed, and that's what not
we wanted to add to the number of printed character or to remove
from the size of the available buffer. Additionally, nothing was
subtracted from the size of the available buffer in doPrint() and
that caused a buffer overflow.
However, we can't support the requirement that the printf-like
functions that accept the buffer and the maximum number of
characters as parameters return the number of characters that
would be printed if the size of the buffer was large enough, if
extended formats were used. The extended formats call Text
functions that don't report how many characters would be printed.
deleted declarations of unused functions from Core spec
added validate function for Text, which reports an Error if
the buffer of managed strings grows over 32K.
Text_putMod was checking if Text is loaded when a module id
higher than 0x7FFF was found. However, if Text is not loaded such
ids are not generated, so the clause that would be executed when
Text is not loaded and an id is higher than 0x7FFF was dead code.
Text doc was claiming Text can accept 64K of strings, but only
15 bits are used to address strings in charTab, which means only
about 32K can be addressed.
XDCTOOLS-326 Recursive calls to System_doPrint lose track of maximum
length allowed