[Implemented] Unsigned bytes

BackupUser · Post by **BackupUser** » Thu Mar 07, 2002 6:45 pm

Restored from previous forum. Originally posted by Rings.

in range from 0-255

Getting better with a little help from my friends....thx Siggi

BackupUser · Post by **BackupUser** » Thu Mar 07, 2002 7:35 pm

Restored from previous forum. Originally posted by MrVainSCL.

Rings wrote
in range from 0-255

Yes, i agree... as i often read on irc last time, there are many people who want and need to have a *.b from 0-255 ... I dont know any basic language where a byte can only handle -127 to +127 ... Please think ybout this...

PIII450, 256MB Ram, 6GB HD, RivaTNT, DirectX8.1, SB AWE64, Win98SE + Updates...

greetz
MrVainSCL! aka Thorsten

BackupUser · Post by **BackupUser** » Thu Mar 07, 2002 8:49 pm

Restored from previous forum. Originally posted by tranquil.

YEAHH!!! THATS IT!

Tranquilizer/ Secretly!
Registred PureBasic User

BackupUser · Post by **BackupUser** » Fri Mar 08, 2002 3:13 pm

Restored from previous forum. Originally posted by Danilo.

Right !!

Its not only a wish, its a *must*.

Without Bytes being Bytes, and Words
being Words, PureBasic is useless
for many things.

There are 2 differnet things, you have
to look at:
1.) Commands that use the value

Thats mostly FredericÂ´s choice.
When Fred thinks the command Str() should
use Signed values, its his choice.
If he also provides a command StrU() for
Unsigned values, its great.

Thats not really the important part, because
we can write our own commands too.

2.) definition and value assignment

Thats the important part, because we cannot
change the compiler !! Only Fred can do that.

Bytes are Bytes in memory, and Words are Words -
the memory cell doesnt care if its signed or unsigned.

The BIG problem:
The compiler doesnt allow:
byte.b = 255
word.w = 65535

But hey, the thing is simple -
the Compiler must allow the following values:

Code: Select all

Bytes  =        -127  ->         255 (       -$7F ->       $FF )
Words  =      -32767  ->       65535 (     -$7FFF ->     $FFFF )
DWords = -2147483647  ->  4294967295 ( -$7FFFFFFF -> $FFFFFFFF )

Fred:
__Please__ change that in the compiler.
You dont have to change 1 PureBasic command
for that, only the allowed Range in the compiler.

Result:
You can still use -127 for Bytes, when you
need it. But you can also use the value 255
and $FF for bytes, for the functions that
need unsigned values (most API functions).

BTW: it already works for LONGs, because its
allowed to write variable.l = $FFFFFFFF (thats good).
But you can also write var.l = -$FFFFFFFF (not good).

For the right allowable values see above.

Thanks,
...Danilo

(registered PureBasic user)

Edited by - Danilo on 10 March 2002 23:20:21

BackupUser · Post by **BackupUser** » Mon Mar 11, 2002 2:36 pm

Restored from previous forum. Originally posted by fred.

Done. But it's not a real unsigned support, it allows just to pass up to 255 to a byte or 65536 to a word. StrU() will display unsigned number correctly.

Fred - AlphaSND

BackupUser · Post by **BackupUser** » Mon Mar 11, 2002 10:30 pm

Restored from previous forum. Originally posted by Danilo.

THANKS Fred !!

I think you can call this unsigned support.
You can use signed and unsigned for variable
declaration.

The only special command is Str(), but thats
not a problem when we have StrU() for unsigned
numbers.

Thank you again,
...Danilo

(registered PureBasic user)

BackupUser · Post by **BackupUser** » Mon Mar 11, 2002 11:26 pm

Restored from previous forum. Originally posted by fred.

No, as the compare will be wrong:

a.b = 255

if a > 128 ; will be a false result as internally PB use signed number

Fred - AlphaSND

BackupUser · Post by **BackupUser** » Tue Mar 12, 2002 8:37 am

Restored from previous forum. Originally posted by Rings.

No, as the compare will be wrong:

a.b = 255

if a > 128 ; will be a false result as internally PB use signed number

Fred - AlphaSND

useless, if this did not work.

a.b=128
select a
case 1
PrintN("Case a = 1")
case 128
PrintN("Case a = 128")
endselect

Edited by - Rings on 12 March 2002 08:40:13

BackupUser · Post by **BackupUser** » Tue Mar 12, 2002 1:22 pm

Restored from previous forum. Originally posted by MrVainSCL.

Mhhh... i still want to use .b up to 255 and not to when i want to check for -255 to write if bla = 128 or something like this... that would be really useless... Because i dont want to code in two different ways when checking any condition i.e.!!

Fred, please let us usw .f, .b, .w, .l like in BlitzBasic on Amiga or any other coding related language... else i think it would be better to let it as it is now...!?

PIII450, 256MB Ram, 6GB HD, RivaTNT, DirectX8.1, SB AWE64, Win98SE + Updates...

greetz
MrVainSCL! aka Thorsten

BackupUser · Post by **BackupUser** » Tue Mar 12, 2002 1:23 pm

Restored from previous forum. Originally posted by MrVainSCL.

Hi Fred
Mhhhh.. could you not rewrite all libs and the core of the compiler to use *.b *.w and so, like in any other lanuage and as this stuff is normaly to handle?????

PIII450, 256MB Ram, 6GB HD, RivaTNT, DirectX8.1, SB AWE64, Win98SE + Updates...

greetz
MrVainSCL! aka Thorsten

BackupUser · Post by **BackupUser** » Tue Mar 12, 2002 5:03 pm

Restored from previous forum. Originally posted by fred.

I don't understand. On BlitzBasic Amiga (and PC) there is no unsigned support. On BlitzPC there is even no word or byte support. Only very few Basic langage support signed byte and word and I don't think it's really necessary. You want use a number above 127 ? Just use a word or a long.

Fred - AlphaSND

BackupUser · Post by **BackupUser** » Tue Mar 12, 2002 8:08 pm

Restored from previous forum. Originally posted by richard.

sure one can do that. but it will break code or the algorithm at times (crypts). maybe you could introduce a new modifier such as .ub, .uw, .ul.

BackupUser · Post by **BackupUser** » Tue Mar 12, 2002 11:14 pm

Restored from previous forum. Originally posted by Danilo.

MrVainSCL wrote:
>else i think it would be better to let it as it is now...!?

Nope !!

We really need something like:

Code: Select all

GUID:
   Data.l $7bf80980
   Data.w $bf32, $101a
   Data.b $8b, $bb, $00, $aa, $00, $30, $0c, $ab

and

Code: Select all

  var.GUID
  var\Data1 = $7bf80980
  var\Data2 = $bf32
  var\Data3 = $101a

for DirectX and COM-Programming (OOP), so please dont
change it back Frederic !!

cya,
...Danilo

(registered PureBasic user)

BackupUser · Post by **BackupUser** » Wed Mar 13, 2002 12:29 am

Restored from previous forum. Originally posted by MrVainSCL.

Fred wrote:
...You want use a number above 127 ? Just use a word or a long...

Hi Fred
I think the main idea behind .b is to use datas up to 255 in the variable and this is old as computer exist... So i dont know, why we should use .w or .l to save datas > 127 like 199... Why should be use .w to store 199 when there is a STANDARD on the computer inudstry, where a .b can be set up 255 !!?????

PIII450, 256MB Ram, 6GB HD, RivaTNT, DirectX8.1, SB AWE64, Win98SE + Updates...

greetz
MrVainSCL! aka Thorsten

BackupUser · Post by **BackupUser** » Thu Mar 21, 2002 10:46 pm

Restored from previous forum. Originally posted by Don.

I've come across a few situations where support for signed values would have made life much easier. I wrote a PB encryption application which used an algorithm called Blowfish. This is heavily dependent on unsigned values.

Another example is if you have a buffer of characters which you're Peek'ing through, say looking for printable characters (>ASCII 31). Any Peek'd character >127 appears as a negative value, which can mess things up unless you're careful.

PB would be more flexible if it had support for unsigned values - although I've always found ways of getting around the limitation, even if it means less elegant code. It would be nice to see this in PB one day though.

Don