Recent changes to bugs

TimSecondsToDateTime problem

Anonymous — Sat, 19 Jul 2008 08:10:45 -0000

Using OS 4.1 on Palm M130 (in emulator)
Onboard C version 2.51

Doing

DateTimePtr dtP;

FrmAlert(GetsToHere);
TimSecondsToDateTime(TimGetSeconds(),dtP);
FrmAlert(NotGetToHere);

Nothing fancy as you can see

Code works on earlier OS versions fine but in OS 4.1
get emulator message

"...wrote to memory location 0x002635DC, which is in the
storage heap. In order to protect the integrity of the user's data such direct access is not allowed. Instead, applications should use special Palm OS functions ..."

macro expansion bug (infinite loop)

Lincoln Ramsay — Tue, 15 Jul 2008 12:00:11 -0000

I wrote this innocuous-looking code...

UInt32 ref;
UInt32 time;
// set ref and time
AlmSetProcAlarm(MyFunc, ref, time);

This causes a hang. It turns out it's an infinite loop.

The problem is that the AlmSetProcAlarm macro uses 'ref' as the second argument. There is a check in the code to handle 'recursive' arguments like this but since I put a space after the comma, this code was foiled.

I have a work around for this (skip over any white space before doing the recursive check) that seems to work fine (both in POSE and onboard).

I've put up a binary for testing at the usual location.
http://ramsay.webhop.org/OnBoard.zip

Crash on bad func ptr typedef

Lincoln Ramsay — Tue, 27 May 2008 21:14:11 -0000

Reported by Gareth on the Yahoo list.

...
Basically the line:

typedef Boolean (FormGadgetHandlerType) (struct FormGadgetType
*gadgetP, UInt16 cmd, void *paramP);

was causing the crash.

I changed it to

typedef Boolean (FormGadgetHandlerType*) (struct FormGadgetType
*gadgetP, UInt16 cmd, void *paramP);

and it compiled fine. It was definitely compile time not runtime.
...

My take on this is that this should be a callback declaration but instead of being a function pointer, it's a regular function and this is probably causing havoc. This really shouldn't crash if we can help it.

OnBoard updates protected and locked resources

Lincoln Ramsay — Wed, 14 May 2008 14:29:28 -0000

OnBoard does not remove the app it is building. If the app already exists, a few key resources are removed and then everything is just copied in.

This has a few problems (eg. can end up with stale crap in the binary that shouldn't be there).

The most annoying and damaging behaviour though is that apps that are protected and locked seem to be overwritten quite happily by OnBoard. My own app (AttnGrab) now has code specifically designed to detect when this has happend so that the device can be reset (it's the only way to avoid a potentially damaging crash).

Firstly, I think that OnBoard should completely remove an app before it creates it. This should not be a Launcher-style delete (that's covered by <a href="https://sourceforge.net/tracker/index.php?func=detail&aid=922486&group_id=55794&atid=500573">this task</a>) but a Filez-style delete.

To prevent the problems I've seen with my app, OnBoard should first see if the app is protected and issue a delete signal as the Launcher does (so that the app can de-register any alarms and notifications and unlock resources). Once the app is no longer protected, the compile can go ahead (it should abort or prompt the user if it the app does not become unprotected).

For bonus points, OnBoard could check to ensure that there are no more alarms/notifications for the app (especially proc-based ones) or locked resources. Clearly though, there's a limit to how much good this will do. If your app doesn't clean up when you get a delete signal, you're screwed when you delete via the launcher anyway.

sizeof() bug

Anonymous — Tue, 20 Feb 2007 17:12:33 -0000

typedef struct {
UInt32 P[18];
UInt32 fieldInfo;
UInt32 S[4][256];
} bf_ctx;

sizeof(bf_ctx) returns -1 instead of 4172.

Float problem

Anonymous — Thu, 21 Dec 2006 15:30:31 -0000

float fkNumber = 123.45;
Char str[40];

StrIToA(str, (Int32) flNumber);

// the .45 appears to be lost in flNumber after the above stmt. ie flNumber now is 123.0

// am I missing something?

Arrays of function pointers not supported

Steve Little — Thu, 05 Oct 2006 16:41:04 -0000

--- In OnBoardC@yahoogroups.com, Sébastien MARQUE
<seb.marque@...> wrote:
>
> but one day I tried to create arrays of functions
pointers. with no
> success, I just did it again to give here the error
messages I get: the
> parser says nothing, but when assembling it says
something like
> "undefined global data label xyz" where xyz is
garbage, and then "global
> fixup to unknown datal label", and then "output
incomplete"
>
>
> here's my try:
>
> typedef Boolean (*ptrfunctype)(FormPtr);
> ptrfunctype ptrfunc[3] = {
> funcA,
> funcB,
> funcC
> };
>
> Boolean funcA (FormPtr pForm) {
> ...
> return true;
> }
> Boolean funcB (FormPtr pForm) {
> ...
> return true;
> }
> Boolean funcC (FormPtr pForm) {
> ...
> return true;
> }
>
> Boolean SomeThing (UInt16 style, FormPtr
pForm) {
> ...
> // possible style values: 0, 1, 2
> return (ptrfunc[style])(pForm);
> }
>
> sure there is a error and it is possible to do, I've
tried different
> ways with pointers to function but after a while I
decided to abandon
> and choose an other way to do my stuff ;)
>
> seb
>

Static array initializer wrong

Jerramy Gipson — Mon, 25 Sep 2006 15:01:26 -0000

When initializing a 2D array will incomplete lists,
the next list is loaded in the wrong spot.

<PRE>
Uint16 array2D[10]10] =
{
{1,2,3,4},
{5,6,7,8},
{9,0}
};
</PRE>

should load the array to be:
1 2 3 4 0 0 0 0 0 0
5 6 7 8 0 0 0 0 0 0
9 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
...

but instead loads it thusly:
1 2 3 4 5 6 7 8 9 0
0 0 0 0 0 0 0 0 0 0
...

Pointer Math (?)

Ken Mankoff — Thu, 07 Sep 2006 00:58:08 -0000

Please improve the Summary if someone has a better
understanding of this.

I have the following function. It will not compile.
This is not cut-and-pasted so please email me if you're
working on this bug and want help.

Boolean foo(const UTF8 *source, const UTF8 *sourceEnd) {
int length = bar[*source]+1;
if (source + length > sourceEnd) {
return false;
}
return true;
}

The error occurs on the source+length line. If I change
it to the following it does compile. I have yet to
completely verify this fix as valid.

Boolean foo(const UTF8 *source, const UTF8 *sourceEnd) {
int length = bar[*source]+1;
UTF8 *spl = source + length;
if ( spl > sourceEnd ) {
//if (source + length > sourceEnd) {
return false;
}
return true;
}

elsewhere: typedef UInt8 UTF8;

UL type not recognized

Ken Mankoff — Thu, 07 Sep 2006 00:51:54 -0000

static UTF32 offsetsFromUTF8[6] = { 0x00000000UL,
0x00003080UL, 0x000E2080UL, 0x03C82080UL, 0XFA02080UL,
0x2082080UL };

Produces the following error:

======================

Unexpected token while

waiting for a unary

expression, line XX
(OK) (Goto)

----------------------

If "UL" is removed it then compiles.