Yeah - the FF: got your attention didn't it :-) Well here's yet another list of "rather give it away than bin it" stuff. All needs collection from London E2 in the next few days. --------------------------------------------------------------------- Full tower ATX case - good quality - no blanking plates left though. Has 5 x 5.25" bays + 2 x 3.5" front bays + floppy bay. Good nick apart...

...d6 d7 d8 d9 da db dc dd de df 0000e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef 0000f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff 000100 C:\Users\epc\temp> - e C:\Documents and Settings\dan\Desktop\gfortran\source>gfortran -o chars ep17.txt C:\Documents and Settings\dan\Desktop\gfortran\bin/ld.exe:ep17.txt: file format not recognized; treating as linker ...

... 98 99 9a 9b 9c 9d 9e 9f 0000a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af 0000b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf 0000c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf 0000d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df 0000e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef 0000f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff 000100 C:\Users\epc\temp> - e

..., you could use a hex editor (e.q. xvi32) or the good old dos debugger ("debug.exe", still comes with windows ?) to see what the four bytes in that fort.10 file actually are. 00 7B FF 01 I was expecting all the char values, as in the following: //mkchars.c: #include <stdio.h> #include <stdlib.h> #include <limits.h> int main(void) { ...

... use a hex editor (e.q. xvi32) or the good old dos debugger ("debug.exe", still comes with windows ?) to see what the four bytes in that fort.10 file actually are. 00 7B FF 01 Translate these to decimal would be 0,123,255,1 Unless I am missing something, this seems to be what the test program you ran should produce. The array named "tr" appears to be holding all 256 ...

... meantime, you could use a hex editor (e.q. xvi32) or the good old dos debugger ("debug.exe", still comes with windows ?) to see what the four bytes in that fort.10 file actually are. 00 7B FF 01 I was expecting all the char values, as in the following: //mkchars.c: #include <stdio.h> #include <stdlib.h> #include <limits.h> int main(void) { FILE ...

..., you could use a hex editor (e.q. xvi32) or the good old dos debugger ("debug.exe", still comes with windows ?) to see what the four bytes in that fort.10 file actually are. 00 7B FF 01 I was expecting all the char values, as in the following: //mkchars.c: #include <stdio.h> #include <stdlib.h> #include <limits.h> int main(void) { FILE *fp; char name[]="chars.256"; ...

...the 256'th one will be avoided by the advance='no'. Now if you used (256A1) for the format, things would be different. THen the format would not get to the end and recert. ! Writes out $00 - $FF correctly! do n=0,255 Write(16,'(A1)',advance="no") achar(n) end do In this case, your format never reverts. The advance='no' prevents the one end-of-record that would ...

...), Thomas Koenig posted: On 2008-07-27, RadSurfer <RadSurfer@yahoo.com> wrote: I am in need for an important project to write out simple unsigned-char values in the range $00 through $FF, without any extraneous data being added: program main integer, parameter :: d1=selected_int_kind(2) integer(kind=d1), dimension(0:255), parameter :: tr = & (/(/(i,i=0,...

... (and absolutely nothing else!) ! Write(16,'(A1)',advance="no") achar(2) ! Writes out $00 - $FF correctly! do n=0,255 Write(16,'(A1)',advance="no") achar(n) end do close(...an important project to write out simple unsigned-char values in the range $00 through $FF, without any extraneous data being added: [Snip] Please identify which compiler. There may ...