@SamuraiCrow
PortablE's type system has nothing much to do with C's. If you want to see how types are supposed to work, then have a look here:
http://cshandley.co.uk/portable/PortablE.html#15_10

Partly due to it's AmigaE heritage, PortablE doesn't even support unsigned integers out-of-the-box. They have to be declared, and as such don't behave quite like PortablE's built-in (primitive) types. (It's certainly an annoyance that PortablE has no proper support for ULONG calculations, as that'd make translating certain C algorithms much much easier. Unfortunately it's no easy to solve, as it'd break assumptions in the type system.)


Anyway, I was right about why UINT isn't behaving as expected. It's because it is NOT declared as you'd expected. Specifically it is declared in 'exec/types' like this:

TYPE UINT IS NATIVE {UWORD} INT

Which on the parser side behaves the same as:

TYPE UINT IS INT

I'm not sure why I did something strange like that. From first glance I'd have thought the following declaration would make more sense:

TYPE UINT IS NATIVE {UWORD} RANGE 0 TO 65535

Then it would behave more like you'd expect (but still not exactly like C).

Possibly I declared them strangely because they were just a quick hack to allow OS headers to compile, and I didn't expect anyone to actually try using them in new PortablE code... I'd have to make the change to 'exec/types' and see if it has (too many) unwanted consequences.

You're writing the rules for PortablE but under ANSI C/C++, unsigned integers are allowed to wrap around without invoking undefined behaviors. Signed integers are another story.

If the 'exec/filesystem.h' doesn't exist, it certainly used to. I assume AROS must have done some reorganising of the includes. It ought to be easy to fix (famous last words), however I don't know when I'll get a chance to look at it... Do you need it fixing urgently?

Not sure about the UINT thing. I haven't tried to replicate this bug myself yet, but some example code might be helpful. It seems a bit strange it would happen, as a UINT should be declared as "TYPE UINT IS RANGE 0 TO 65535", so the parser ought to know it's range... The most likely explanation is that UINT is not defined like that! BTW, the type resulting from adding two UINTs together should be "RANGE 0 TO 131070" unless I am mistaken.

I have attached a PNG image (pointlessly Zip compressed again for the forum attachment) of an IcAros 2.0.3 session under VirtualBox. The two windows indicate that the expression parser incorrectly interpreted two UINT variables being added together having the wrong range: -65536 TO 65534 (should be 0 to 65534). Also the resultant GCC compile from the PEGCC shows that the AROS version is trying to #include a file called 'exec/filesystem.h' that doesn't exist under IcAros.

The configuration is 512 MiB RAM and two hardfiles, one for the program documents, one for the actual IcAros distribution. Both hardfiles are fixed in size.

If these are known bugs, I apologize for the bother.

Attach file:

---

Link only for registered users