Hi Viktor
Pls try again with current SVN, if the 'open' crash
disappeared.
Yes, the 'open' crash disappeard. Thanks!
Yes, hbmake and hbdoc are the "black sheeps" in the
Harbour distro. No one is using them from the core
contributors and no one reported any problems with
them before the release either (this bug was there
since about 6 months), so such may happen :(
There are other bugs that have been in them from the inception.
Exactly for the above reasons these tools almost
didn't even make it into the final release, and
I just feel more and more compelled to move them to
/contrib/examples/ or /contrib/utils/. They have new
separate make files (bld_*.bat in the local dirs),
so anyone (with BCC or MSVC) can easily build them
now separately.
I don't know of anyone that's actively using them. I use hbmake because it's
so easy. I doubt it would work on any system other than DOS/Windows.
[ Even hbdoc has most of those file reading problems
that you've mentioned before. Also, hbdoc has a very
difficult time with non-Windows/DOS systems, and
these tools are generally unsupported even in xhb.
hbmake doesn't work if HB_COMPAT_C53 is turned off,
the code quality is below Harbour standard, and so
on and so on. ]
Yes, in fact in December 2007 when you suggested that I fix hbdoc, I did
rewite all the modules in the order they were listed by invoking hbdoc
without parameters down to the -htm -ht2 parameters. I discovered that MS
never released the (new doc) format for the -ht2 parameter.
However, I discovered a flaw in xHarbour's hb_fReadLine() function and
reported it. I waited several weeks but they never fixed it. It's still
present in the freadline() that Harbour uses that was borrowed from
xHarbour. In fact, it's the exact same error I discussed with you about the
file functions you just fixed so hbmake will work. The error is still in
these functions as well.
In reading text lines, these functions only get the first line correct for
Microsoft OSes which have CRLF ending. The functions will eat the CR leaving
the LF as the first character of all suceeding lines. Only the first line is
correct. I just wrote a small program to insure nothing has changed. In
xHarbours favor is that the error only happens if you use an array of line
ending terminators that have proper subsets of array elements that aren't
unique. Still errors are errors and I can't use the routine on many
conversion projects because of this error. The program and output is below:
// Program to check hb_freadLine() with array of EOLs with common elements
function main()
LOCAL cLine, nHandle:= fOpen( "fread.prg" )
LOCAL c1stChar
IF nHandle < 1
Alert("Couldn't open input file: fread.prg" )
RETURN -1
ENDIF
Clear Screen
? "1st Char of line in Hex and the rest of the Line"
WHILE hb_freadline( nHandle, @cLine, { Chr(13)+Chr(10), Chr(13) } ) == 0
c1stChar:= HB_NumToHex( Asc( Left( cLine, 1 ) ) )
? c1stChar, SubStr(cLine, 2 )
END WHILE
RETURN 0
-----------------------------------------------
Program Output
1st Char of line in Hex and the rest of the Line
66 unction main()
A LOCAL cLine, nHandle:= fOpen( "fread.prg" )
A LOCAL c1stChar
A
A IF nHandle < 1
A Alert("Couldn't open input file: fread.prg" )
A RETURN -1
A ENDIF
A
A Clear Screen
A ? "1st Char of line in Hex and the rest of the Line"
A WHILE hb_freadline( nHandle, @cLine, { Chr(13)+Chr(10), Chr(13) } ) == 0
A c1stChar:= HB_NumToHex( Asc( Left( cLine, 1 ) ) )
A ? c1stChar, SubStr(cLine, 2 )
A END WHILE
A
A RETURN 0
C:\Source\fRead>
The 1st line has '66 unction main()' which is correct for the first line
since 0x66 is 'f' this would make the first line function main(). All the
other lines have hex A which is the LF left over from the CRLF. Instead of
taking the longest EOL, freadline() takes the shortest EOL.
After this I gave up on sending you the hbdoc that I had fixed. Why have two
different ways of getting the same problem?
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
