Frank Heckenbach wrote:
I assume Peter's description in the announcement of GPC-970624 in 199706250026.CAA18851@agnes.dida.physik.uni-essen.de can be considered authoritative:
--- BEGIN QUOTE ---
- GPC has new integer types now. Below is a table with their sizes in bits and their equivalents in (GNU) C.
[....]
Yes, that is authoritative enough :-) Thanks!
Procedures assgined to procedural variables can be in the main program now, so you can remove this comment for ExitProc.
I am still having some problems with this.
Can you show us an example where this is a problem, so it can be fixed?
I had a problem with it in TESTMEM.PAS in the new bpcompat. However, I have since discovered that the problem lies in mixing the use of "ExitProc", and "AddExitProc" in the same program. Use one or the other, and the problem disappears. Use both == infinite loop.
Another detail concerning ExitProc: There is a little difference between how BP's and GPC's system.pas handle them. BP sets them to NIL before calling an ExitProc. The effect is, when an exit proc "forgets" to assign the next one to ExitProc, the chain will abort rather than infinitely calling the same exit proc. I think the following would be 100% compatible:
to end do begin var Tmp: Pointer; while ExitProc<>nil do begin InOutRes := 0; Tmp := ExitProc; ExitProc := NIL; PProcedure (Tmp)^ end end;
Okay - thanks. I have replaced the code in SYSTEM.PAS with this one.
Assign is built-in now, so you can remove it from system.pas.
Actually, the CygWin32 version still does not have it - so I have left it there (to be compiled only if __CYGWIN32__ is defined).
Unit Printer:
can be written now (at least for DJGPP).
Done!
BTW: Do you close the printer file it in a "to end do" statement? BP, AFAIK, doesn't do so, but it's better to do.
Yes, I do. I have not seen BP's implementation. I only read about it in the help file and wrote some code to do the same thing (i.e., assign, and rewrite the Lst variable in a "to begin do" statement, and then close it in a "to end do" statement). This is all that the unit does (and from what I can see, that is all it needs to do).
Yes, it is. This is how it is implemented in "AddNull", which was in the strings unit before, but I have now moved it into the system unit, since the system unit also uses that functionality.
Any thoughts on whether the system unit should now export this AddNull function so that it can be available globally? This would introduce something which is not in the BP system unit.
I'm not sure if it should, since something like this will be built-in later, so programs shouldn't rely on the version in system.pas. Besides, I think, the name "AddNull" could be unclear or ambiguous (though I doubt someone would write a procedure of this name operating on numbers... ;-). I'd rather call it something like "Str2CString" or so...
Since all that it does is add a null terminator, perhaps I can call it "AddNullTerminator". The problem is that if it is not exported in the SYSTEM unit, then I have to implement it in several units, because the use of that functionality is widespread.
Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12@keele.ac.uk Author of: Chief's Installer Pro 4.01 for Win16 and Win32: Winner of PC PLUS Magazine Gold Award (April 1995 U.K. edition) http://ourworld.compuserve.com/homepages/African_Chief/
ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief401.zip