Status

From Freepascal Amiga wiki
Revision as of 13:36, 29 August 2013 by Molly (talk | contribs) (Fixed typo: C does not use "^." but "->" for pointer types.)
Jump to navigation Jump to search

Known Bugs and strange Features

Problem: Pathnames

  • especially relative pathes <-> absolute pathes.
  • Many programs in aros are just recompiled from unix/linux, that they are able to work there are functions to work with unix style pathnames some programs even support both methods.

Example: parent dir in AROS = "/" Unix Style root: "/" so if my program get a "/System/abc" this could mean:

  • one dir up then folder "System" and folder "abc" (treated Amiga style path)
  • System:abc (treated as Unix style path)

Its impossible to say which one is right.

Bug: Not enough memory

  • After a while working with fpc/ld and so on you will get strange behaviour of AROS. Programs will fail with "Not enough memory" even Avail shows much free space.
  • It's not completely clear whats the problem here, seems some kind of memory leak or open handles which blocks Aros to this state - needs to be inspected.

Inconsistency: AllocASLRequest...() function names

In ASL unit there are two functions defined for Allocating a requester 1) AllocAslRequest [1] (which is the varargs version) and 2) AllocAslRequestA [2] (which is the tagpointer version).

But both SDK [3] and Aros [4] documentation states that AllocAslRequestTags is the varargs stub and AllocAslRequest the tagpointer version.

Note that there is no mention of an AllocAslRequestA() function at all. FWIW: this inconsistency was introduced in original Amiga units long time ago, mainly because ASL Author didn't follow 'normal' stub function naming.

Inconsistency: accessing certain (linked) parts in a structure

This is another legacy issue. Sometimes you want to (indirectly) access a certain field of a structure but this field cannot be reached by following the usual path. This is because the type/structure that is defined in FreePascal (and that you need/want to use in order to access the final field) is not 'properly' defined.

Let's view an example to make this more clear. In C you can do something like: mycolormap = mywindow->WScreen->ViewPort.Colormap;

In the Pascal definition of structure Window the field WScreen is defined as being a (plain) pointer. Therefor you are unable to access further underlying fields. In this specific example this can be circumvented by typecasting the WScreen pointer as being a pointer to the structure Screen, like this:

mycolormap := pScreen(mywindow^.WScreen)^.ViewPort.ColorMap;

Currently there are more of these kind of inconsistencies present in the FreePascal units. The reason for this is both old and boring (memory restrictions, speed-issues, etc), but the most important one is circular/forward type referencing, which (in FreePascal) is only possible within the same scope of a Type section. Different (Type) sections are not allowed to 'mingle'/reference types. Most of these issues could be prevented by re-organizing the defined Type sections from a unit in such a way that this issue is cut down to a minimum.

Incompatibility: Wrong defined parameters/result

Although AROS specific units (which represent/contain AROS specific libraries) are distributed in the current package, not all of them are 100% fully compatible with AROS.

This can sometimes result in strange behaviour when using certain functions from a library using the function from it's corresponding unit.

As an example take a look at the DOSFlush() function from unit AmigaDOS. It states that the function returns a boolean as result value. Making use of this function as currently defined can be hazardous twofolded:

  • firstly, it let's the user believe a returned true value would mean the function was succesfull (which is untrue as returned C-boolean works different from pascal booleans)
  • secondly, a boolean value in Pascal has a size of 1 byte while the actual return value has the size of a LONG value (which could have several impact, including wrong stack usage).

There are numurous of those 'issues' spreaded amongst even so many different units. Ofcourse these 'issues' should be taken care of. (FWIW: it is a work in progress).

In the case of the DOSFlush() example, the function should return a LongBool (which is Freepascal's equivalent of LONG that could be checked against the 'value' true or false). Unfortunately the SDK documentation was very 'clever' to not define the size of the return value D0, but AROS documentation does.

There is no good good workaround for such issues other then re-defining the function yourself, declaring the correct parameters/result types/sizes and calling the actual library function.

If you should encounter such issues, then please report them to us, so that the issue can be dealt with.

Not Implemented: Specific declarations/implementations that are currently missing

The following items are missing (are currently not implemented). The list shows the type of the item that is missing, before the colon. (Type = Type definition missing; Varargs = Varargs (stub) function not implemented, Macro = Macro not defined). After the semicolon (and before the dot) you can read to which specific (AROS) unit the item is related (e.g. exec for exec unit, intuition for intuition unit etc.). After the dot you can read the literal name of the item that is missing (e.g. if you try to use that part literarely in sourcecode, the code will not be compiled and the compiler throws you an error because the item does not exist).

  • Type: exec.CONST_STRPTR
  • Varargs: (graphics.)ObtainBestPen()
  • Macro: graphics.SetDrPt()
Retrieved from "http://fpcamigawiki.alb42.de/index.php?title=Status&oldid=53"