Prof A Olowofoyeku wrote:
On 14 Dec 2003 at 0:56, Waldek Hebisch wrote:
[...]
Address have to be properly aligned. Unaligned reference may couse crash (some RISC machines, notably SPARC and AFAIK early PPC) or data corruption (ARM). If the backend belives that data is aligned it may generate fullword access even for characters (when copying arrays). So GPC would have to duplicate backend checks and accept/reject program depending on target characteristics. ATM I can not say how hard would be to implement such behaviour, but the end result look really like a loss:
Previous versions of GPC permitted this, and the code worked correctly both on Sparc (Solaris) and x86 (Windows and Linux). So it would seem that all that needs to happen is for what was done in recent times to be undone when not using any of the ISO standards.
Maybe I overreacted, but recently I fixed an ARM bug, when backend lost track of alignment... However, your code may be fine but similar code may fail (if a field requires better then byte alignment and happens to be misaligned). I have not looked at relevant code in GPC (Frank did the change) but I suspect that GPC just happily generated wrong code (in some cases). Pascal philosophy (adapted by most modern languages) is to catch problems at compile time. It is hard to be sure that a problem will appear, so the language forbids anything which _may_ be incorrect.
program correctness would depend on rather on rather complex platform dependent alignment rules
program portability would decline
small modifications to data layout would convert valid program into invalid one
I am not sure about any of these. But what has happened is that the new restrictions have broken code that has existed and worked happily under GPC for a very long time.
Well, I frequently have the same feeling. But I also keep finding blatant errors in code that "worked happily" for years. So I am very sceptical about changes that reduce error checking in the compiler. IMHO if reduced error checking is needed it should be localised, so that other parts of the program (or other programs) still are checked. One possibility could be "customisable" (skinable??) language -- where the user would specify exactly (say, in a config file) which constucts are allowed. But that would complicate GPC quite a lot...
IMHO it much better to restructure the program. For example just use auxilary variable
That would be quite tedious, but it might well be what I will have to do (or use older versions of GPC for the affected code).
I corrected similar problem (type mismatch between record field and a var parameter) in Stanford Pascal (~ 10000 lines of code, tens of calls to correct). The correction is not very nice, but after about 1 hour I was done. In your case it would look like: { In declaration section } Type tsig = array [ 0..3 ] OF Char; foo = packed record sig : tsig; end;
{ At apropriate scope} Var foo_aux : tsig; Var f : foo;
begin foo_aux := f.sig; StrCopy (foo_aux, 'OK'); f.sig := foo_aux end.
(of course for `StrCopy' there is no need for the first assignment, but I want to show general case). Tedious -- yes, but can be done quickly.
and copy the field (or pack/unpack the whole record) when needed.
I am not sure how to do that ...
I basically challenge your need to have a packed record. You can copy the whole record to an unpacked one (tedious if you have many fields but may be less work then previous approach) and back when needed.
If my wild guess is correct you need packed record to match file header. Then the best way may be to copy it to unpacked record on reading file and copy to packed one on writing.
Finally, if you really want quick&dirty solution the following seem to do what you want:
program packer; uses Strings; Type {$pack-struct, maximum-field-alignment 8} foo = record sig : array [ 0..3 ] OF Char; end; {$no-pack-struct, maximum-field-alignment 0}
Var f : foo; begin StrCopy (f.sig, 'OK'); writeln (f.sig[0], f.sig[1]) end.