I just wanted to say I LOVE the fact that the compiler warns you of these mundane details.

Personally, I don't consider my application at a good stopping point unless I can make all the warnings go away. Sometimes I even will put in (hopefully a low overhead thing when I do it) a meaningless command to remove "variable not initialized" warnings... when I KNOW I'm doing something to init the variable that the compiler can't (nor is expected to) know I'm doing that.

Example:

Procedure HiWorld;
Var MyVariable: ansistring;
Begin
  MyVariable:=MyVariable; // this is a workaround in rare cases.
  CallAReferenceProcedure(MyVariable); // This is warning material.
End;

Note: I know it MAY create a few assembly instructions - but I think I'll take a couple of them to hush the compiler.

It seems like a "CLEAN" thing to do... I mean, it raises doubt (speaking for myself) when I compile something and there are warnings being displayed. It makes me think the programmer has not addressed everything or my environment might be the cause of said application to maybe not work as designed.

Jason P Sage

I have tested the FPC supplied MySQL4 unit and I've admittedly haven't had a ton of time to play with it yet. But I was curious if any of you had any feedback about it.

I wrote a wrapper for the FPC supplied MySQL3 a long time ago and it worked awesome. I think I should do the same for MySQL4, and perhaps someone is working on a MySQL5 unit for FPC now.

So, my questions can be summarized with: If you used the MySQL4 unit in FPC, do you have any comments you could share?

Thank You,

Jason P Sage

Hi,
It's me again. I was wondering if anyone has run into a problem where programs that used the CRT unit and have worked for both Linux and win32 find that these same programs no longer work on newer lynx's?

I have this whole suite of code - literally megs of source code that works on Win32 and used to work on some older distros of Linux years back. When I got them to compile in FPC 2, and they ran on Windows, they would not run on Redhat Fedora 5 Linux.

I did find that I could probably write an old BBS ANSI'ish alternative to the CRT unit and maybe make the calls pretty compatible or something - dropping some legacy TERMINFO stuff etc.... just using escape sequences for maybe VT400 and Linux console or something.

(Which my efforts to emulate the CRT calls themselves I've had problems with
- I don't understand all the constructs for some things - but that is me... and frankly I'd rather use what works(worked) before))

Does anyone know what might be different in current Linux distros that's not handled like before that might contribute to the CRT unit not working on my Fedora 5?

A good example is that FreeVision and the FPC IDE do not work on my Linux either.

Thanks - this one has baffled me for awhile. One solution would be to make a wrapper to the CRT unit, and depending if I'm Linux or not, use CRT stock lock and barrel, and use a home made lean terminal emulator for Linux. Does this sound like a good or bad idea?

Thank You Again!
Jason P Sage

The mysql 5 unit has been available since a long time.

So, my questions can be summarized with: If you used the MySQL4 unit in FPC, do you have any comments you could share?

Mysql 3 and 4 are relatively compatible, the only area needing some changes are the connection routines.

Michael.

MyVariable:=MyVariable; // this is a workaround in rare cases.

Can anybody that knowns the internals of FPC confirm if this will create extra work/code for the compiler? I have been trying for a long time to figure out a clean way of getting rid of some compiler warnings.

Regards,
Graeme.

Graeme Geldenhuys wrote

> MyVariable:=MyVariable; // this is a workaround in rare cases. Can anybody that knowns the internals of FPC confirm if this will create extra work/code for the compiler?

It does create an assignment. At least with the fpc2.0.2 version I just checked:

Compiled with "-al" for source lines and "-O3":

|.Ll2:
| .stabn 68,0,10,.Ll2 - P$TEST_ASSIGN
|# [10] x := x;
| movl -4(%ebp),%eax

Without optimization it even generates:

| .stabn 68,0,10,.Ll2 - P$TEST_ASSIGN
|# [10] x := x;
| movl -4(%ebp),%eax
| movl %eax,-4(%ebp)

Depending on the view point and application it might be negligible. It's probably not a good idea to do that inside a tight loop, but in most other cases those couple of bytes won't hurt.

Although, well ... I wouldn't depend on that behaviour, because the variable still *is* as uninitialized as before, because the right hand side of the expression assigned to it is. So if someone cares to write code for a more stricter data flow analysis, the warning may at some time reappear.

So this is no clean way to do it I'd say.

What is needed is a way to tell the compiler: "Trust me. I know what I'm doing."[1] ;)

Vinzent.

[1] "{$SLEDGE_HAMMER ON}"?

Graeme Geldenhuys wrote

> MyVariable:=MyVariable; // this is a workaround in rare cases. Can anybody that knowns the internals of FPC confirm if this will create extra work/code for the compiler?

It will.

I have been trying for a long time to figure out a clean way of getting rid of some compiler warnings.

Michael.

Jason P Sage wrote

A good example is that FreeVision and the FPC IDE do not work on my Linux either.

Elaborate on "do not work" please ?

Micha