* *
* partial sync with the 3.4 fork codebase. These are the things
synces for the most part:
- copyright headers
- grammar/typos in comments and some readmes
- comment/whitespace/decorations
- variable scoping in C files
- DO CASE/SWITCH and some other alternate syntax usage
- minimal amount of human readable text in strings
- minor code updates
- HB_TRACE() void * casts for pointers and few other changes to
avoid C compiler warnings
- various other, minor code cleanups
- only Harbour/C code/headers were touched in src, utils, contrib,
include. No 3rd party code, no make files, and with just a few
exceptions, no 'tests' code was touched.
- certain components were not touched were 3.4 diverged too much
already, like f.e. hbmk2, hbssl, hbcurl, hbexpat
- the goal was that no actual program logic should be altered by
these changes. Except some possible minor exceptions, any such
change is probably a bug in this patch.
It's a massive patch, if you find anything broken after it, please
open an Issue with the details. Build test was done on macOS.
The goal is make it easier to see what actual code/logic was changed
in 3.4 compared to 3.2 and to make patches easier to apply in both
ways.
* package/harbour.spec
* contrib/hbbz2/hbbz2.hbp
* package/mpkg_rpm.sh
+ added support for '--with localbz2' RPM build parameter
* include/hbpp.h
* src/pp/ppcore.c
* src/compiler/hbmain.c
* modified hb_pp_inBuffer() parameters. Now it supports optional
szFileName parameter.
Warning: it's incompatible with previous version but I do not think
that anyone used this function outside core code so I decided to not
add new function but simply change the existing one.
[INCOMPATIBLE]
* src/rtl/filebuf.c
! do not resepct SET DEFAULT/PATH in hb_fileExists() when 2nd parameter
is NULL in default file IO drivers. It also changes the behvior of
PRG function hb_vfOpen() which now honors SET DEFAULT/PATH only if
its 2nd parameter is passed by reference - this modification is
compatible with 2016-01-25 18:16 UTC+0100 Viktor Szakats in his fork.
* src/rdd/dbf1.c
* src/rdd/dbfcdx/dbfcdx1.c
* src/rdd/dbfnsx/dbfnsx1.c
* src/rdd/dbfntx/dbfntx1.c
* updated to work correctly with modified hb_fileExists() behavior
; CL5.2 DBFCDX and Six3 CDX/NSX RDDs looking for production indexes
respect SET PATH but Harbour in core DBF* index RDDs is CL5.3/COMIX
compatible and looks for production indexes only in the directory
where DBF file is located and only SIXCDX Harbour RDD is CL5.2/Six3
compatible.
Please also note that it's significant only for situations when
DBF file is located in current directory. If it's open from
SET DEFAULT/PATH directory then corresponding path is added
to DBF file name what effectively disables SET DEFAULT/PATH
processing when production index is open.
* src/rtl/filebuf.c
* src/rtl/filebufd.c
* src/rtl/iousr.c
* contrib/hbmemio/memio.c
; cleaned name of hb_fileCopy() paramter
* include/hbapifs.h
* src/rtl/filebuf.c
* src/harbour.def
+ added new C function:
HB_BOOL hb_fileMove( const char * pszSrcFile,
const char * pszDstFile );
* src/rtl/vfile.c
* include/harbour.hbx
* src/harbour.def
+ added new PRG function:
hb_vfMoveFile( <cFileSrc>, <cFileDst> ) -> <nResult>
; unlike hb_fileRename()/hb_vfRename() new hb_fileMove()/hb_vfMoveFile()
functions allow to move files between different file systems/drives
and also different Harbour file IO drivers. Please note that it means
that file name IO driver prefix is significant in both source and
destination file names unless it's local FS operation. New functions
when both file names point to the same Harbour file IO driver try to
use simple rename operation. If it fails then they try to copy the
file and remove the source one.
* ChangeLog.txt
! typo
* include/hbfloat.h
* contrib/xhb/xhbctbit.c
* src/compiler/hbcmplib.c
* src/compiler/hbcomp.c
* src/compiler/hbusage.c
! pacified new GCC warnings and partially synced with Viktor's fork
* src/compiler/hbusage.c
* added Klas Engwall to credits list
* added Rolf to credits list
* updated April White email address
; please verify it and update if necessary
* *
% remove brandings and homepage [1] from copyright header. Pass 1 - using script.
[1] nobody has access to it anymore AFAIK - and it's also just
a redirect since long
! update url in copyright header
; this should make the diff between 3.4 and 3.2 easier to manage
* contrib/hbtip/encurlc.c
! fixed C&P typos in tip_URLEncode() and tip_URLDecode() in may
previous commit
* src/pp/ppcore.c
* pacified warning
* src/common/hbver.c
* src/rtl/hbsocket.c
* updated for Digital Mars C compilation
* src/pp/ppcore.c
! restored previous algorithm for scanning #included files when included
file is given without path
Now the following(Cl*pper compatible) file search algorithm is used
for files which are not marked as system headers (system headers are
enclosed in <>):
1) if file name contains absolute path then open the file from
the given location. If path starts with drive letter then
is always used as absolute path regardless of used path separator
after drive delimiter: ":"
2) if file name contains relative path then open then:
a) try to access included file starting from current directory
b) try to access included file starting from the path taken from
the first compiled file in list of included files
c) check INCLUDE paths (paths specified by -I compile switch and
taken from INCLUDE envvar)
3) if file name does not contain any path then open then:
a) try to access included file starting from the path taken from
the first compiled file in list of included files (if it does
not have any path then starting from current directory)
b) check INCLUDE paths (paths specified by -I compile switch and
taken from INCLUDE envvar)
For files marked as system headers in #include directive (enclosed in <>)
the file name is always used as relative path and Harbour scans only
INCLUDE paths (-I and INCLUDE envvar). It's Harbour extension, Cl*pper
does not support system headers.
; Maybe we should think about adding yet another step between (b) and (c)
in case 2 above and between (a) and (b) in case 3:
- try to access included file starting from the path taken from
the file with #include directive
It should help to create nested projects using relative paths. Maybe
it should even have the highest priority. It could be important only
in case of file name conflicts.
* src/pp/ppcore.c
! fixed directory include precedence in #included files which
are not marked as system headers (system headers are enclosed in <>)
Now the following order is used:
1) try to access included file as is starting from current directory
2) if included file has relative path then check if the first
compiled file has path and if yes try to access file using this
path as start point
3) check INCLUDE paths (envvar and -I parameter)
Previous version used: 2 for nested files or 1 for first file or when
first file was given without path then 3.
Now we are Cl*pper compatible but such version strongly depends on
current directory which has the highest priority. Personally I do no
like such behavior because it may give different results when current
directory is changed.
* include/hbapifs.h
* src/rtl/filebuf.c
* move HB_FILE_TYPE_MAX definition to header file
% include C stat() header only in *nix builds
* src/pp/ppcore.c
! force stringify when illegal characters are included inside
square brackets []
* contrib/hbtip/utils.c
* src/rtl/gtwvt/gtwvt.c
* casting to pacify some warnings
* src/compiler/harbour.y
* src/compiler/harbour.yyc
* src/compiler/harbour.yyh
* changed type of valChar.length from int to HB_SIZE
* include/hbpp.h
* src/pp/ppcore.c
* changed type of last hb_pp_tokenBlockString() parameter
from int * to HB_SIZE *
* src/compiler/complex.c
* removed unnecessary casting
* include/hbpp.h
* src/pp/ppcore.c
* replaced compile time macro HB_PP_MULTILINE_STRINGS with
runtime #pragma setting, i.e.:
#paragma multilinestrings = on
* src/vm/hashes.c
% resize index during hash arrays sorting, i.e. when strict order
is disabled or user call HB_HSORT() function
! fixed typo in timestamp value comparison - in practice only date
part was significant
! fixed new code I added recently for resorting hash arrays with
strict order
* bin/check.hb
! made it work regardless of cwd
+ added --fixup option to fix/process files
+ extended detection of SVN IDs based on 'ident' option
in .gitattributes. Now also warn if missing.
+ added detection of C++ style comments in C files
+ ported Harbour function name casing fixup code, so
it can now be done automatically before commit
* bin/commit.hb
* minor change in option name
* contrib/gtwvg/wvgwin.c
* contrib/gtwvg/wvgwing.c
! deleted large amount of MSDN documentation in C++ comments
! fixed C++ comments
* src/pp/ppcore.c
* avoid false C++ comment detection in deffed out
non-code section
* src/rtl/gttrm/gttrm.c
* contrib/rddads/adsx.c
* contrib/xhb/filestat.c
! fixed C++ comment
* contrib/hbrun/hbrun.hbp
* utils/hbmk2/hbmk2.hbp
+ better comment
* extras/gtwvw/hbgtwvw.h
* extras/gtwvw/*.c
! fixed C++ comments
* (all files)
* stripped svn header
* minor cleanups
; use following command to find out the history of files:
git log
git log --follow
git blame
git annotate