Re: [fpc-pascal] ask some reference books
yeah...I've read all the PDFs under the folder.They are quite useful. thanks. 2008/8/13, Francisco Reyes <[EMAIL PROTECTED]>: > > On 10:29 pm 08/11/08 "Galloplus Chang" <[EMAIL PROTECTED]> wrote: > > Would you please recommand some useful reference books for Free > > Pascal or other Pascal-related language,such like objectPascal and > > Have you checked the Documents section in the http://freepascal.org site? > http://www.freepascal.org/docs.var > > There are PDFs you can download. > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help with Free Pascal - RTL!!
Hello SirStorm25 Didn't expect to see you here. Check the top of system unit and systemh.inc and you'll find out why. -- View this message in context: http://www.nabble.com/Help-with-Free-Pascal---RTL%21%21-tp18952131p18958772.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Compiler option to check return value ignorance
Sometimes we forgot whether a function argument is passed by reference or by value. What if the result is actually important? For instance, consider the following (WARNING: True story): function Align(Addr: Pointer; Alignment: PtrUInt): Pointer; then we forgot that Addr is passed by value, so instead of stating APointer:=Align(APointer,TheAlignment); we only call Align(APointer,TheAlignment); which is harmful as we may need to have the pointer aligned. It's useful, believe me (Nimrod even doesn't allow it without a special statement). PS: I think a warning (or note or hint, whichever suits best) is enough. -- View this message in context: http://www.nabble.com/Compiler-option-to-check-return-value-ignorance-tp18958911p18958911.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
Op woensdag 13-08-2008 om 01:27 uur [tijdzone -0700], schreef leledumbo: > > Sometimes we forgot whether a function argument is passed by reference > or by > value. What if the result is actually important? For instance, > consider the > following (WARNING: True story): That's not so strange story. I think this is one of the (if not the) most common mistakes of beginning programmers. And -as always- sometimes the most experienced also make this mistake. And there's no way the compiler can detect this. Because this could be intentional. If you'll give a warning on such a construct, I think about 50% of the procedures would gresult in such a warning... And the rules are simple: (for the beginners) procedure Align(Addr: Pointer; Alignment: PtrUInt); -> This procedure can't change any of it's parameters procedure Align(const Addr: Pointer; Alignment: PtrUInt); -> This procedure can't change any of it's parameters, and Addr can't be changed inside the procedure also. procedure Align(var Addr: Pointer; Alignment: PtrUInt); -> This procedure can change Addr If you really need those warnings, you could learn yourself to always use 'const', 'var' or 'out'. And never without any of these words. Joost ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
Joost van der Sluis wrote: > > And there's no way the compiler can detect this. > I don't think so. The compiler understand that a procedure doesn't return a value while a function does (i.e. trying to return a value from a procedure causes compile error). I haven't checked how compiler formats each function/procedure in the PPU but I think there should be an information whether it's a function or procedure. So, I think it's possible to detect if a function call is assigned to a variable or not. -- View this message in context: http://www.nabble.com/Compiler-option-to-check-return-value-ignorance-tp18958911p18960053.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help with Free Pascal - RTL!!
leledumbo wrote:
>
> Hello SirStorm25
>
> Didn't expect to see you here. Check the top of system unit and
> systemh.inc and you'll find out why.
>
Neither did I!!!
I think I get it now :) , so, I have to change {$undef
FPC_HAS_FEATURE_TEXTIO} in system.pas to {$define FPC_HAS_FEATURE_TEXTIO} ?
Regards
SirStorm25.
--
View this message in context:
http://www.nabble.com/Help-with-Free-Pascal---RTL%21%21-tp18952131p18960065.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help with Free Pascal - RTL!!
SirStorm25 wrote:
>
> so, I have to change {$undef FPC_HAS_FEATURE_TEXTIO} in system.pas to
> {$define FPC_HAS_FEATURE_TEXTIO} ?
>
Well... just try it =^D
How can you use file related functions without any file system support
(don't worry, I'm working on it B-))?
--
View this message in context:
http://www.nabble.com/Help-with-Free-Pascal---RTL%21%21-tp18952131p18960153.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help with Free Pascal - RTL!!
leledumbo wrote:
>
>
> SirStorm25 wrote:
>>
>> so, I have to change {$undef FPC_HAS_FEATURE_TEXTIO} in system.pas to
>> {$define FPC_HAS_FEATURE_TEXTIO} ?
>>
> Well... just try it =^D
> How can you use file related functions without any file system support
> (don't worry, I'm working on it B-))?
>
Well, Im trying to see if I can simply get it to load a text file in the iso
and display it on the console. But, sadly, whenever I do define the TextIO
feature, it comes with many more problems %-| , here are the errors that
come from text.inc:
text.inc(21,11) Error: Identifier not found "Do_Close"
text.inc(27,20) Error: Identifier not found "Do_Read"
text.inc(39,14) Error: Identifier not found "Do_Write"
text.inc(60,10) Error: Identifier not found "Do_Open"
text.inc(72,20) Error: Identifier not found "Do_Isdevice"
text.inc(201,12) Error: Identifier not found "Do_Erase"
text.inc(211,15) Error: Identifier not found "Do_Rename"
text.inc(294,26) Error: Identifier not found "Do_Isdevice"
text.inc(303,36) Error: Identifier not found "Do_FilePos"
text.inc(347,16) Error: Identifier not found "do_seek"
text.inc(636,13) Fatal: Unknown compilerproc "fpc_widestr_to_ansistr". Check
if you use the
correct runtime library.
I guess that fatal one is because I haven't defined WideStrings.
But, the others, I have no idea about them!!!
Regards
SirStorm25.
--
View this message in context:
http://www.nabble.com/Help-with-Free-Pascal---RTL%21%21-tp18952131p18960362.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help with Free Pascal - RTL!!
Well, for the iso... I guess it's possible to read files stored in it. Grub can read menu.cfg, so why can't we? The problem is... how? -- View this message in context: http://www.nabble.com/Help-with-Free-Pascal---RTL%21%21-tp18952131p18960532.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
leledumbo wrote:
Joost van der Sluis wrote:
And there's no way the compiler can detect this.
I don't think so. The compiler understand that a procedure doesn't return a
value while a function does (i.e. trying to return a value from a procedure
causes compile error). I haven't checked how compiler formats each
function/procedure in the PPU but I think there should be an information
whether it's a function or procedure. So, I think it's possible to detect if
a function call is assigned to a variable or not.
Yes. Turn Extended Syntax off {$X-}, then a function result must be
assigned to a variable. At least it used to be that way.
I was used to it, and in the case I really needed to ignore the result
(and rather just wanted the side-effects of the function) I wrote things
like:
|if (IOResult <> 0) then {null};
Well, then ... I started with classes:
Now, constructors seem to actually return something (not surprisingly),
so "inherited Create" did not compile anymore (and I remember that any
attempt to assign this "result" to a dummy variable even failed). So, at
that time I turned the extended syntax stuff back on.
So, in theory your problem is already solved in the compiler (even TP6
already had it), but alas, in practice it's not really usable.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Translate C to Pascal
Mattias Gaertner wrote:
On Tue, 12 Aug 2008 09:39:36 +0200
Jilani Khaldi <[EMAIL PROTECTED]> wrote:
Marc Weustink wrote:
Micha Nelissen wrote:
Mattias Gärtner wrote:
How to translate this:
struct a;
Isn't this a forward declaration? So sometime later it needs to
declare 'struct a { ... };' ?
If not, can't it be translated as:
a: record end;
?
Yes, it can.
Thanks. I will use that.
What for? The C statement is empty, it's not a variable and not even a
type. So before translating that into an empty Pascal-record, you should
rather look at what the actually used structur in the C-code is.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Converting C's bit field struct
Since no one answers on message board, I'll post it here.
C struct:
typedef unsigned int u32int;
typedef struct page
{
u32int present: 1; // Page present in memory
u32int rw : 1; // Read-only if clear, readwrite if set
u32int user : 1; // Supervisor level only if clear
u32int accessed : 1; // Has the page been accessed since last
refresh?
u32int dirty : 1; // Has the page been written to since last
refresh?
u32int unused : 7; // Amalgamation of unused and reserved bits
u32int frame : 20; // Frame address (shifted right 12 bits)
} page_t;
Pascal record please...
--
View this message in context:
http://www.nabble.com/Converting-C%27s-bit-field-struct-tp18959002p18959002.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Translate C to Pascal
On Wed, Aug 13, 2008 at 7:38 AM, Vinzent Höfler <[EMAIL PROTECTED]> wrote: > What for? The C statement is empty, it's not a variable and not even a type. > So before translating that into an empty Pascal-record, you should rather > look at what the actually used structur in the C-code is. It is usually used for having an opaque type, referencing it with a pointer. I would put in pascal both the empty structure and a pointer type to it. a: record end; pa: ^a; -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting C's bit field struct
Found on the net that Pascal doesn't provide it :-(( What if FPC creates it as an extension =)? -- View this message in context: http://www.nabble.com/Converting-C%27s-bit-field-struct-tp18959002p18960630.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Translate C to Pascal
Felipe Monteiro de Carvalho wrote: On Wed, Aug 13, 2008 at 7:38 AM, Vinzent Höfler <[EMAIL PROTECTED]> wrote: What for? The C statement is empty, it's not a variable and not even a type. So before translating that into an empty Pascal-record, you should rather look at what the actually used structur in the C-code is. It is usually used for having an opaque type, referencing it with a pointer. I would put in pascal both the empty structure and a pointer type to it. But then the structures won't match, opaque or not. Mattias provided no context to his original question, so I don't know if it would impose a problem, but usually I leave those things out until I really need them. The type as is has no storage size associated to it, so it can't even be used that way in the C-code. Sure, you can have a pointer to it, but unless you cast the hell out of it, it still won't do any good. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting C's bit field struct
leledumbo schreef: Found on the net that Pascal doesn't provide it :-(( What if FPC creates it as an extension =)? FPC supports bitpacked records. I cannot find it in the docs right now. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting C's bit field struct
leledumbo wrote:
Since no one answers on message board, I'll post it here.
C struct:
typedef unsigned int u32int;
typedef struct page
{
u32int present: 1; // Page present in memory
u32int rw : 1; // Read-only if clear, readwrite if set
u32int user : 1; // Supervisor level only if clear
u32int accessed : 1; // Has the page been accessed since last
refresh?
u32int dirty : 1; // Has the page been written to since last
refresh?
u32int unused : 7; // Amalgamation of unused and reserved bits
u32int frame : 20; // Frame address (shifted right 12 bits)
} page_t;
Hmm. That's nasty. ;)
> Pascal record please...
Should be something like that:
type
Unsigned_7 = 0 .. (1 shl 7) - 1;
Unsigned_20 = 0 .. (1 shl 20) - 1;
type
page_t = bitpacked record
present : boolean;
rw : boolean;
user : boolean;
accessed : boolean;
dirty: boolean;
unused : Unsigned_7;
frame: Unsigned_20;
end;
I guess, portability is of no concern with such a structure. ;)
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
Vinzent Höfler wrote:
>
> Yes. Turn Extended Syntax off {$X-}, then a function result must be
> assigned to a variable. At least it used to be that way.
> ...
> so "inherited Create" did not compile anymore (and I remember that any
> attempt to assign this "result" to a dummy variable even failed). So, at
> that time I turned the extended syntax stuff back on.
>
So, if I don't use any classes, turning Extended Syntax Off would be OK?
What's activated by this Extended Syntax anyway? Any document/article about
it?
--
View this message in context:
http://www.nabble.com/Compiler-option-to-check-return-value-ignorance-tp18958911p18960807.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
leledumbo wrote:
Vinzent Höfler wrote:
Yes. Turn Extended Syntax off {$X-}, then a function result must be
assigned to a variable. At least it used to be that way.
...
so "inherited Create" did not compile anymore (and I remember that any
attempt to assign this "result" to a dummy variable even failed). So, at
that time I turned the extended syntax stuff back on.
So, if I don't use any classes, turning Extended Syntax Off would be OK?
I guess so. Haven't tried it in years, though.
What's activated by this Extended Syntax anyway? Any document/article about
it?
http://www.freepascal.org/docs-html/prog/progsu108.html#x116-1160001.2.32
With Turbo/Borland Pascal there were some other subtle differences (like
- I think - treating an array of char as string/PChar), but the main
effect was the throwing away of function results.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help with Free Pascal - RTL!!
leledumbo wrote: > > Well, for the iso... I guess it's possible to read files stored in it. > Grub can read menu.cfg, so why can't we? The problem is... how? > If we could get those functions working it might be possible, but text.inc doesn't like to be compiled in this case :-( . If we could get the code for these functions and place them in one single file maybe... readwritelib.pas, but thats all the ideas I have. Unless we could try and invent our own functions for reading files. But that might take even longer! Any Ideas??? :confused: Regards SirStorm25. -- View this message in context: http://www.nabble.com/Help-with-Free-Pascal---RTL%21%21-tp18952131p18960976.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting C's bit field struct
Vincent Snijders wrote: > > FPC supports bitpacked records. I cannot find it in the docs right now. > Oh... didn't know if such a thing exists. Vinzent Höfler wrote: > > type > Unsigned_7 = 0 .. (1 shl 7) - 1; > Unsigned_20 = 0 .. (1 shl 20) - 1; > > type > page_t = bitpacked record >present : boolean; >rw : boolean; >user : boolean; >accessed : boolean; >dirty: boolean; >unused : Unsigned_7; >frame: Unsigned_20; > end; > Weird... never seen anything like this before :confused:, but I'll try. Thanks. -- View this message in context: http://www.nabble.com/Converting-C%27s-bit-field-struct-tp18959002p18961028.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Translate C to Pascal
Zitat von Vinzent Höfler <[EMAIL PROTECTED]>: >[...] > >>> a: record end; > > > > Thanks. I will use that. > > What for? The C statement is empty, it's not a variable and not even a > type. So before translating that into an empty Pascal-record, you should > rather look at what the actually used structur in the C-code is. Actually the C-Code does what C can do really good: obfuscating. If I understand the code correct, the 'struct a;' itself is never used directly. It always uses 'struct a* foo'. So foo is a pointer to an empty struct a, which probably is the C equivalent of a typed pointer. To get strong type checking, I guess, it is ok to follow Felipe's advice: type a = record end; pa=^a; Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting C's bit field struct
On Wed, 13 Aug 2008, leledumbo wrote: > > Found on the net that Pascal doesn't provide it :-(( > What if FPC creates it as an extension =)? FPC has it, but only in MacPas mode. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting C's bit field struct
Michael Van Canneyt schreef:
On Wed, 13 Aug 2008, leledumbo wrote:
Found on the net that Pascal doesn't provide it :-((
What if FPC creates it as an extension =)?
FPC has it, but only in MacPas mode.
I copied the example program from: http://qc.codegear.com/wc/qcmain.aspx?d=56480
Added {$mode delphi} or {$mode objfpc} and the program compiled without errors.
Vincent
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Translate C to Pascal
Mattias Gärtner wrote: Zitat von Vinzent Höfler <[EMAIL PROTECTED]>: [...] a: record end; Thanks. I will use that. What for? The C statement is empty, it's not a variable and not even a type. So before translating that into an empty Pascal-record, you should rather look at what the actually used structur in the C-code is. Actually the C-Code does what C can do really good: obfuscating. Yeah. If I understand the code correct, the 'struct a;' itself is never used directly. It always uses 'struct a* foo'. So foo is a pointer to an empty struct a, which probably is the C equivalent of a typed pointer. To get strong type checking, I guess, it is ok to follow Felipe's advice: type a = record end; pa=^a; Well, I guess so, but it still doesn't make a lot of sense. That "struct a" is not empty (storage size = 0), it is even non-existant (storage size = unknown). So the C-code may shuffle around the pointers, but unless this "struct a" (the "a" not even being a type here) is instantiated somewhere (internally in some library code?) such pointers are merely typed "void*". Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting C's bit field struct
Hello,
Am 13.08.2008 um 13:23 schrieb Vincent Snijders:
Michael Van Canneyt schreef:
On Wed, 13 Aug 2008, leledumbo wrote:
Found on the net that Pascal doesn't provide it :-((
What if FPC creates it as an extension =)?
FPC has it, but only in MacPas mode.
I copied the example program from: http://qc.codegear.com/wc/
qcmain.aspx?d=56480
Added {$mode delphi} or {$mode objfpc} and the program compiled
without errors.
Bitpacked records have been implemented and/or greatly improved for
all platforms some time ago by Jonas; there were some problems with
the "old" implementation iirc. Bitpacked records are also supported
in other modes than macpas mode, however I do not know whether it has
been intentional to enable them in Delphi mode.
Regards,
Thomas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Translate C to Pascal
Zitat von Vinzent Höfler <[EMAIL PROTECTED]>: > Mattias Gärtner wrote: > > Zitat von Vinzent Höfler <[EMAIL PROTECTED]>: > > > >> [...] > > a: record end; > >>> Thanks. I will use that. > >> What for? The C statement is empty, it's not a variable and not even a > >> type. So before translating that into an empty Pascal-record, you should > >> rather look at what the actually used structur in the C-code is. > > > > Actually the C-Code does what C can do really good: obfuscating. > > Yeah. > > > If I understand the code correct, the 'struct a;' itself is never used > directly. > > It always uses 'struct a* foo'. So foo is a pointer to an empty struct > > a, which probably is the C equivalent of a typed pointer. To get strong > type > > checking, I guess, it is ok to follow Felipe's advice: > > > > type a = record end; pa=^a; > > Well, I guess so, but it still doesn't make a lot of sense. > > That "struct a" is not empty (storage size = 0), it is even non-existant > (storage size = unknown). So the C-code may shuffle around the pointers, > but unless this "struct a" (the "a" not even being a type here) is > instantiated somewhere (internally in some library code?) such pointers > are merely typed "void*". The c compiler does not need the internals, so should the pascal bindings. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC Lazarus Snapshot link
I can't seem get through to the Laz snapshot page which is provided from the Wiki page. http://www.de.freepascal.org/lazarus/ Thank you for posting links to all the Laz info. That makes things much easier :) -R Ward ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Lazarus Snapshot link
Richard Ward schreef: I can't seem get through to the Laz snapshot page which is provided from the Wiki page. http://www.de.freepascal.org/lazarus/ That is an old link. IT should be http://www.hu.freepascal.org/lazarus/ Where did you find that link? Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mac & WinCe
Felipe Monteiro de Carvalho wrote: On Tue, Aug 12, 2008 at 2:34 PM, Jeff Wormsley <[EMAIL PROTECTED]> wrote: Does this support MIPS based CE devices, or only ARM? Most people are using ARM, and that's what the pre-compiled compiler is for. Some people experiment with x86-wince, but I never tested this myself. The compiler does not support MIPS. I thought that might be the case. I have an old Casio Cassiopea BE-300 that is MIPS based, and using Visual C to write apps for it is a pain, so I was hoping... But alas, no, and it wouldn't be worth it to try to add MIPS support, because as you note, ARM has taken over the PDA market. Jeff. -- I haven't smoked for 1 year, 11 months and 3 weeks, saving $3,273.26 and not smoking 21,821.74 cigarettes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
Op woensdag 13-08-2008 om 02:52 uur [tijdzone -0700], schreef leledumbo: > > Joost van der Sluis wrote: > > > > And there's no way the compiler can detect this. > > > I don't think so. The compiler understand that a procedure doesn't return a > value while a function does (i.e. trying to return a value from a procedure > causes compile error). I haven't checked how compiler formats each > function/procedure in the PPU but I think there should be an information > whether it's a function or procedure. So, I think it's possible to detect if > a function call is assigned to a variable or not. Ok, so I misunderstood you. You want that the compiler complains if you don't assign the result of a function. While that can be done, I don't think you want that. This functionality is used far too often, and those warnings would become very annoying. Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EOLESysError calling CreateOLEObject
Umm ... so can I assume that it wasn't merged? Maybe it could at least be merged to 2.2.3 thanks, On Tue, Jul 22, 2008 at 12:58 PM, Felipe Monteiro de Carvalho <[EMAIL PROTECTED]> wrote: > On Tue, Jul 22, 2008 at 10:59 AM, Marco van de Voort <[EMAIL PROTECTED]> > wrote: >> Fixed, added some more clsid constants in the process r11434 > > Could the fix be merged to 2.2.2? > > I would like to use the example in the Lazarus book, which will most > likely come after 2.2.2 > > thanks, > -- > Felipe Monteiro de Carvalho > -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EOLESysError calling CreateOLEObject
Felipe Monteiro de Carvalho schreef: Umm ... so can I assume that it wasn't merged? Maybe it could at least be merged to 2.2.3 What revision do you want to be merged. I thought r11434, but that has made it all the way into fpc 2.2.2, as far as I can see: http://svn.freepascal.org/cgi-bin/viewvc.cgi/tags/release_2_2_2/packages/winunits-base/src/shlobj.pp?view=log Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EOLESysError calling CreateOLEObject
Yes, that was it =) Excellent. I assumed it wasn't merged because no answer was given to my e-mail. This is pretty good for that part of the book =) thank you, -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EOLESysError calling CreateOLEObject
> Yes, that was it =) > > Excellent. I assumed it wasn't merged because no answer was given to my > e-mail. > > This is pretty good for that part of the book =) Well, that fix, and the win32/win64 can use more than 2GB fix (peflags directive) should be the only differences between rc2 and the final release. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
Joost van der Sluis wrote:
Ok, so I misunderstood you. You want that the compiler complains if you
don't assign the result of a function. While that can be done, I don't
think you want that.
Well, don't decide for others, please. I am a stupid programmmer, I am
making mistakes all the time, and any feature that could possibly stop
me from making such is - in my opinion - a useful feature.
I *wanted* it, even have used that feature for years - until "inherited
Create" came disguised as a function. Unfortunately {$X} can't be used
locally and always accounts for the whole compilation unit, so you can't
even use it to temporarily switch on the extended syntax in the few
places where it would be needed (like I sometimes turn off range checks
locally) and any other attempts to circumvent that problem just failed.
I just tested again and found something weird. Turning off "Extended
Syntax" actually disables compilation of constructors at all, so it
wasn't even only a problem with the "inherited Create" as I remembered.
Look at this:
-- 8< -- snip --
{$MODE OBJFPC}
{$X-}
program
Ext_Syntax;
type
Foo = class (tObject)
public
constructor Create;
end;
constructor Foo.Create;
begin
inherited Create;
if Assigned (inherited Create) then {null};
end;
var
A : tObject;
begin
A := Foo.Create;
end.
-- 8< -- snip --
Compiles fine with {$X+} (line 2). Now let's turn extended syntax off as
shown and wonder:
|ext_syntax.pas(16,4) Error: Illegal expression
Ok, line 16 is the one with the "inherited Create" on its own. Meets the
expectation, although it might not be intuitive, but well, even
constructors can fail, so it might not even be the worst idea to check
that. ;)
Workaround in the line 17 (dummy test) seems to compile though, so let's
disable line 16 completely:
|ext_syntax.pas(15,1) Error: Operation ">" not supported for types
|"Pointer" and "Pointer"
Huh? Line 15? The "begin" line?
This happened a couple of years ago with 2.0.0, still happens with
2.0.2. Haven't given it a shot in 2.2.x yet, but at least now I remember
why I had to turn on extended syntax for the whole project back then.
This functionality is used far too often, and those
warnings would become very annoying.
It might not be common sense anymore, but the term "function" is often
overloaded as a "subroutine without side-effects". Means, if you don't
interprete the return value you may as well not call it at all.
Of course, in practice, far too many "functions" have side-effects and
often it's just the side-effect you need. But that doesn't mean that
{$X-} wouldn't be useful at all.
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
Vinzent Höfler schreef: Joost van der Sluis wrote: Ok, so I misunderstood you. You want that the compiler complains if you don't assign the result of a function. While that can be done, I don't think you want that. Well, don't decide for others, please. I am a stupid programmmer, I am making mistakes all the time, and any feature that could possibly stop me from making such is - in my opinion - a useful feature. Yes, but this feature doesn't because it gives so many false positives that I end up ignoring such warnings completely. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Understanding the .bin format
Hi all! Does anyone have the specification for the .bin (binary) file type? Regards SirStorm25. -- View this message in context: http://www.nabble.com/Understanding-the-.bin-format-tp18968139p18968139.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
Hi All!!!
Im trying to develop reading capabilities for an OS im helping to develop.
When enabling the FPC_HAS_FEATURE_TEXTIO from the RTL, I get a few errors
involving
the file: Text.inc.
All of the errors returned are mainly "do_" functions.
E.g:
do_read
do_write
do_close
do_erase
dp_rename
etc...
any ideas on stopping this? Anyone know if I have to enable another
define? I've tried {$define FPC_HAS_FEATURE_FILEIO}, but, no luck! :(
Regards
SirStorm25.
--
View this message in context:
http://www.nabble.com/FPC_HAS_FEATURE_TEXTIO---Strange-behaviour%21-tp18968260p18968260.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
Vincent Snijders wrote:
Vinzent Höfler schreef:
Joost van der Sluis wrote:
Ok, so I misunderstood you. You want that the compiler complains if you
don't assign the result of a function. While that can be done, I don't
think you want that.
Well, don't decide for others, please. I am a stupid programmmer, I am
making mistakes all the time, and any feature that could possibly stop
me from making such is - in my opinion - a useful feature.
Yes, but this feature doesn't because it gives so many false positives
that I end up ignoring such warnings completely.
IBTD. I actually *used* that feature, until it became unusable due to
the inability to compile constructors at all. So don't get me wrong, but
maybe I am in a better position to judge its usefulness. Especially
because it doesn't generate warnings, it simply refuses to compile. So
you can't even choose to ignore it.
I just grep'ped the actual sources of the project (about 70K LOC) and I
found exactly four occurences of my "if Ignore_Result() then {null};"
pattern with FPC runtime routines. There are others, but those routines
access hardware and on some occasions I really need to ignore failures
there.
2x IOResult
1x SysUtils.DeleteFile
1x BaseUnix.fpChMod
Twice more of this pattern occured to avoid the compiler hint of unused
parameters. So if "false positives" is an indicator for uselessness of a
compiler message, I'd tend to doubt the usefulness of that.
Well, I even think that pointing the maintenance programmer to the fact
that I deliberately chose to ignore the return value instead of possibly
having forgotten it, might help understanding the code better.
At last, there's a pretty good reason why in some (C-)coding standards
it is even mandatory to cast unused function results to (void). Although
I'd sure find it a bit annoying to write "(void) printf ("Foo");". But
contrary to Pascal procedures, C only knows functions and almost any of
it returns something that's non-void, useful or not. ;)
Vinzent.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
In our previous episode, SirStorm25 said: > Im trying to develop reading capabilities for an OS im helping to develop. > When enabling the FPC_HAS_FEATURE_TEXTIO from the RTL, I get a few errors > involving > the file: Text.inc. > All of the errors returned are mainly "do_" functions. > E.g: > do_read > do_write > do_close > do_erase > dp_rename > etc... > > any ideas on stopping this? Implement them. You enabled the generic part of textio with that define, so the missing functions are the OS dependant primitives you need to implement for your OS. Look at the other implementations (e.g. Dos or linux) to get a clue about what they are supposed to do. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Understanding the .bin format
In our previous episode, SirStorm25 said: > Does anyone have the specification for the .bin (binary) file type? Depends. If you mean in an executable format, then it is usually already relocated code, to be loaded on some OS dependant address. Some variants also have hints for load address and/or entry point. In the general case: the file equivalent of "array of byte". ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
Vinzent Höfler schreef: Vincent Snijders wrote: Vinzent Höfler schreef: Joost van der Sluis wrote: Ok, so I misunderstood you. You want that the compiler complains if you don't assign the result of a function. While that can be done, I don't think you want that. Well, don't decide for others, please. I am a stupid programmmer, I am making mistakes all the time, and any feature that could possibly stop me from making such is - in my opinion - a useful feature. Yes, but this feature doesn't because it gives so many false positives that I end up ignoring such warnings completely. IBTD. I actually *used* that feature, until it became unusable due to the inability to compile constructors at all. So don't get me wrong, but maybe I am in a better position to judge its usefulness. Sorry, that I misjudge your position to judge its usefulness and I misunderstood the difference between a new warning and an old fatal error. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Understanding the .bin format
Hi! > Does anyone have the specification for the .bin (binary) file type? No. Because there is no such ".bin format". File name extensions (e.g. ".bin") are NOT the file format[1] (e.g. JPEG image)! Unfortunately Windows strives to let people assume that, but it is wrong. The extension is an arbitrary part of the file name. Not more, not less. Foolishly Windows uses this as specification of the file format (e.g. when associating programs to start when double-clicking a file in the Explorer). It even tries to assure this by warning you when you modify the extension. All this lets user assume that the extension says something about the content. Again, this assumption is generally wrong (despite often it is by accident right). So, if you have a file with a certain extension, you can not rely on its format. This is especially true for files with such generic extensions like ".bin" (short for "binary") or ".dat" (short for "data"). This extensions are used by hundreds of different programs, each with a totally different formats. Bye Hansi [1] File Format: specifies the meaning of the individual bits and bytes at certain locations in a file ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
Marco van de Voort wrote: > > In our previous episode, SirStorm25 said: >> Im trying to develop reading capabilities for an OS im helping to >> develop. >> When enabling the FPC_HAS_FEATURE_TEXTIO from the RTL, I get a few errors >> involving >> the file: Text.inc. >> All of the errors returned are mainly "do_" functions. >> E.g: >> do_read >> do_write >> do_close >> do_erase >> dp_rename >> etc... >> >> any ideas on stopping this? > > Implement them. You enabled the generic part of textio with that define, > so > the missing functions are the OS dependant primitives you need to > implement > for your OS. > > Look at the other implementations (e.g. Dos or linux) to get a clue about > what they are supposed to do. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > > Hello! Any ideas where to find the source to a version of DOS with those functions implemented, linux source code always gets me confused %-| Regards SirStorm25. -- View this message in context: http://www.nabble.com/FPC_HAS_FEATURE_TEXTIO---Strange-behaviour%21-tp18968260p18968903.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
In our previous episode, SirStorm25 said: > Any ideas where to find the source to a version of DOS with those functions > implemented, linux source code always gets me confused %-| They are not implemented in dos but FOR dos, in the Free Pascal RTL, dos version, dir rtl/go32v2 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
On 13 Aug 08, at 11:47, SirStorm25 wrote: > Marco van de Voort wrote: > > > > In our previous episode, SirStorm25 said: > >> Im trying to develop reading capabilities for an OS im helping to > >> develop. > >> When enabling the FPC_HAS_FEATURE_TEXTIO from the RTL, I get a few errors > >> involving > >> the file: Text.inc. > >> All of the errors returned are mainly "do_" functions. > >> E.g: > >> do_read > >> do_write > >> do_close > >> do_erase > >> dp_rename > >> etc... > >> > >> any ideas on stopping this? > > > > Implement them. You enabled the generic part of textio with that define, > > so > > the missing functions are the OS dependant primitives you need to > > implement > > for your OS. > > > > Look at the other implementations (e.g. Dos or linux) to get a clue about > > what they are supposed to do. > > Any ideas where to find the source to a version of DOS with those functions > implemented, linux source code always gets me confused %-| If you want to contribute to others involved in similar work (porting RTL/unit system to a new platform) in the future, you can add the missing descriptions on our (unfinished) wiki page related to this topic - see http://wiki.freepascal.org/System_unit_structure. I and other core team members are certainly willing to correct / extend your descriptions and answer any remaining questions you'd have after viewing some implementation of those routines (and checking functionality of the used API calls for the particular target platform if not known by you from the top of your head) and trying to describe them. This way the description becomes available for others, not just you. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
Found em! The finaly question is: where do I put these? do I create my own sysfile.inc with just these functions, or do they rely on other functions located within the same file? Regards SirStorm25. -- View this message in context: http://www.nabble.com/FPC_HAS_FEATURE_TEXTIO---Strange-behaviour%21-tp18968260p18970120.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
Vinzent Höfler wrote:
I just grep'ped the actual sources of the project (about 70K LOC) and
I found exactly four occurences of my "if Ignore_Result() then
{null};" pattern with FPC runtime routines. There are others, but
those routines access hardware and on some occasions I really need to
ignore failures there.
2x IOResult
1x SysUtils.DeleteFile
1x BaseUnix.fpChMod
Twice more of this pattern occured to avoid the compiler hint of
unused parameters. So if "false positives" is an indicator for
uselessness of a compiler message, I'd tend to doubt the usefulness of
that.
So, if I read you correctly, if you call a function that you don't care
what the result is, instead of:
Begin
SomeFunction(123); // Ignore result
End;
... you would have us write:
Var Dummy: SomeType;
Begin
Dummy := SomeFunction(123);
End;
... or else get warnings from the compiler?
I'm afraid there are tons of code out there that this would effect. I
don't think any of the maintainers of such code would appreciate that
change much. Maybe, just maybe, an optional {$MODE
ULTRA_STRICT_FUNCTION_RESULT_USE} type compiler option, whose default
was off, would be ok, but otherwise such a change would be far worse
than the "problem" you are trying to address (someone improperly not
using the function result when they were supposed to).
Jeff.
--
I haven't smoked for 1 year, 11 months and 3 weeks, saving $3,274.62 and
not smoking 21,830.81 cigarettes.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
In our previous episode, SirStorm25 said: > > Found em! > The finaly question is: where do I put these? > do I create my own sysfile.inc with just these functions, or do they rely on > other functions located within the same file? Yes, usually per OS the porter maintains a rtl/ dir for general OSes, those dirs are in FPC repository, and 3rd party ones maintain such dirs in private. Note that in general you want to include rtl/inc and rtl/. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
Original-Nachricht
> Datum: Wed, 13 Aug 2008 16:02:10 -0400
> Von: Jeff Wormsley <[EMAIL PROTECTED]>
> An: FPC-Pascal users discussions
> Betreff: Re: [fpc-pascal] Compiler option to check return value ignorance
>
> Vinzent Höfler wrote:
> > I just grep'ped the actual sources of the project (about 70K LOC) and
> > I found exactly four occurences of my "if Ignore_Result() then
> > {null};" pattern with FPC runtime routines. There are others, but
> > those routines access hardware and on some occasions I really need to
> > ignore failures there.
> >
> > 2x IOResult
> > 1x SysUtils.DeleteFile
> > 1x BaseUnix.fpChMod
> >
> > Twice more of this pattern occured to avoid the compiler hint of
> > unused parameters. So if "false positives" is an indicator for
> > uselessness of a compiler message, I'd tend to doubt the usefulness of
> > that.
> So, if I read you correctly, if you call a function that you don't care
> what the result is, instead of:
>
> Begin
> SomeFunction(123); // Ignore result
> End;
>
> ... you would have us write:
>
> Var Dummy: SomeType;
> Begin
> Dummy := SomeFunction(123);
> End;
>
> ... or else get warnings from the compiler?
Apart from the fact that I write
|if not SomeFunction <> Constant_Of_Sometype then {null};
yes. And it's a compile time error.
> I'm afraid there are tons of code out there that this would effect. I
> don't think any of the maintainers of such code would appreciate that
> change much.
I didn't ask for a change. The feature is already there.
All I would ask for that {$EXTENDED_SYNTAX OFF} wouldn't be equivalent to "I
refuse to compile constructors" (and maybe in turn allow the use of "inherited
Create" without this strict check).
Sure, I won't force anyone to use it. But I know environments where your
employer would force you to. Even worse, there are environments where merely
assigning the result to a dummy variable wouldn't be enough to satisfy the
strict checks, you'd have to do something useful with it. And to be honest,
there aren't many cases where you really can ignore the result of the function
and keep the good conscience of having it done right. If a function in Pascal
returns something it's usually useful.
Vinzent.
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler option to check return value ignorance
> |if not SomeFunction <> Constant_Of_Sometype then {null};
Of course, usually it's without the "not"... ;) And with Boolean functions it's
a bit easier.
And I should have added that I never put in comments what I can easily put in
code. At first, comments don't get compiled, and second, nobody never seems to
read them, anyway.
Vinzent.
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
The only problem I've found, is that the do_ procedures contain a line of code: syscopytodos, which seems to be specific to dos, any ideas as to where this function is stored? Regards SirStorm25. -- View this message in context: http://www.nabble.com/FPC_HAS_FEATURE_TEXTIO---Strange-behaviour%21-tp18968260p18970658.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
In our previous episode, SirStorm25 said: > > The only problem I've found, is that the do_ procedures contain a line of > code: > syscopytodos, which seems to be specific to dos, any ideas as to where > this function is stored? In go32v2, but they are very dos specific. Remember, this is the dos specific part of the RTL. How to implement this on your OS, depends totally on the specifics of your OS. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
Would the OS still compile if I removed the syscopytodos and syscopyfromdos functions from the do_ procedures? -- View this message in context: http://www.nabble.com/FPC_HAS_FEATURE_TEXTIO---Strange-behaviour%21-tp18968260p18970901.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
In our previous episode, SirStorm25 said: > > Would the OS still compile if I removed the > syscopytodos and syscopyfromdos functions from > the do_ procedures? Yes of course. It wouldn't work though. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
Nooo! What are these functions meant to do? This seems way more harder than it looks! Regards SirStorm25. -- View this message in context: http://www.nabble.com/FPC_HAS_FEATURE_TEXTIO---Strange-behaviour%21-tp18968260p18970979.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC_HAS_FEATURE_TEXTIO - Strange behaviour!
In our previous episode, SirStorm25 said: > > Nooo! > What are these functions meant to do? > This seems way more harder than it looks! Well that is not that hard: do_read - read bytes from file do_write - write bytes to file do_close - close file do_erase - open file do_rename - rename file etc. _BUT_ the devil is in the details, most notably you must wrap the errorhandling of your OS to match FPC's (which is a bit doslike). For this, take the RTL of any OS you are familiar with, and study it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting C's bit field struct
On 13 Aug 2008, at 11:59, Vinzent Höfler wrote:
leledumbo wrote:
Since no one answers on message board, I'll post it here.
C struct:
typedef unsigned int u32int;
typedef struct page
{
u32int present: 1; // Page present in memory
u32int rw : 1; // Read-only if clear, readwrite if set
u32int user : 1; // Supervisor level only if clear
u32int accessed : 1; // Has the page been accessed since last
refresh?
u32int dirty : 1; // Has the page been written to since last
refresh?
u32int unused : 7; // Amalgamation of unused and reserved bits
u32int frame : 20; // Frame address (shifted right 12 bits)
} page_t;
Hmm. That's nasty. ;)w
> Pascal record please...
Should be something like that:
type
Unsigned_7 = 0 .. (1 shl 7) - 1;
Unsigned_20 = 0 .. (1 shl 20) - 1;
type
page_t = bitpacked record
Yes and no: the layout of bitpacked records is by no means guaranteed
to be the same as that of a C record, regardless of the definition of
the C record. The internal format of bitpacked records is opaque and
must not be used in any case where data has to be interchanged or
where a particular layout is desired.
Jonas___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting C's bit field struct
Original-Nachricht > Datum: Wed, 13 Aug 2008 22:03:23 +0100 > Von: Jonas Maebe <[EMAIL PROTECTED]> > An: FPC-Pascal users discussions > Betreff: Re: [fpc-pascal] Converting C\'s bit field struct > > On 13 Aug 2008, at 11:59, Vinzent Höfler wrote: > > > Should be something like that: > > > > type > > Unsigned_7 = 0 .. (1 shl 7) - 1; > > Unsigned_20 = 0 .. (1 shl 20) - 1; > > > > type > > page_t = bitpacked record > > Yes and no: the layout of bitpacked records is by no means guaranteed > to be the same as that of a C record, regardless of the definition of > the C record. Well, this is obviously a hardware structure and the actual layout should be checked regardless of the definition in C (IIRC, the C-standard doesn't guarantee any particular layout on such records neither). > The internal format of bitpacked records is opaque and > must not be used in any case where data has to be interchanged or > where a particular layout is desired. There was a reason why I brought up the portability issue. Honestly, what do you propose to mimic such stuff? I remember, we already had a discussion about that a couple of months ago. ;) I don't want to bring up Ada again, but ... some years ago I implemented such nasty stuff for an embedded system. You might take a look for the implementation of system structures in that language http://www.gmx.de/mc/h9DZhQD3l4X4hfKafRIagg6e3PI6TW . Well, apart from Endianess issues, successful compilation virtually guarantees the layout. I hope the link works, currently I don't own any web-space... Just click on that "GMX MediaCenter starten" button... Vinzent. -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
