ReadByte/ReadAsciiCharacter return value on error

Everything else that doesn't fall into one of the other PB categories.
BarryG
Addict
Addict
Posts: 3292
Joined: Thu Apr 18, 2019 8:17 am

Re: ReadByte/ReadAsciiCharacter return value on error

Post by BarryG »

Josh wrote:Exactly the same nonsense as your claim that a byte value in a file cannot contain -1.
Please post a screenshot of a hex editor showing -1 for a byte value in a file. All I see is $00-$FF (0-255) for any file.
Last edited by BarryG on Sun Feb 16, 2020 11:11 pm, edited 2 times in total.
User avatar
Josh
Addict
Addict
Posts: 1183
Joined: Sat Feb 13, 2010 3:45 pm

Re: ReadByte/ReadAsciiCharacter return value on error

Post by Josh »

BarryG wrote:I don't see how those two are different.
'Returns the read byte or zero if there was an error' says that zero is returned if an error occurs. But how do you get the idea to draw a return conclusion from this? When I say that it rained on the 31.01.2020, then it does not say that it is the 31.01.2020 when it is raining.
BarryG wrote:Please post a screenshot of a hex editor showing -1 for a byte value in a file. All I see is $00-$FF (0-255) for any file.
I'm sorry, but you disqualify yourself with this. It is not the task of the forum and certainly not mine to teach you the basic concepts of data processing. Use the Help and search for 'Variables and Types' or search the forum for 'signed' and 'unsigned'. But if you've really had read this thread, the answer is already there.
Last edited by Josh on Sun Feb 16, 2020 2:17 pm, edited 1 time in total.
sorry for my bad english
BarryG
Addict
Addict
Posts: 3292
Joined: Thu Apr 18, 2019 8:17 am

Re: ReadByte/ReadAsciiCharacter return value on error

Post by BarryG »

I know perfectly well about byte ranges in CODE being -128 to +127. But code is not what we're talking about in this thread, which is: when reading a FILE, that file will only contain 0 to 255 values, as evidenced in any hex editor. But reading 0 (zero) for a value means both an error when reading the file, or no error because it's a valid value for that read. It shouldn't be both.
User avatar
Josh
Addict
Addict
Posts: 1183
Joined: Sat Feb 13, 2010 3:45 pm

Re: ReadByte/ReadAsciiCharacter return value on error

Post by Josh »

BarryG wrote:I know perfectly well about byte ranges in CODE being -128 to +127 ... that file will only contain 0 to 255 values ...
Well, the problem are usually not the people who don't understand something. The problem are usually the people who think they understand something, but don't.

Believe what you believe, doesn't matter to me. I give up.
sorry for my bad english
User avatar
Kurzer
Enthusiast
Enthusiast
Posts: 664
Joined: Sun Jun 11, 2006 12:07 am
Location: Near Hamburg

Re: ReadByte/ReadAsciiCharacter return value on error

Post by Kurzer »

BarryG,

a byte is represented by 8 bits. In RAM memory, these are (simply spoken) 8 transistors that store either state 1 or 0.
There is no 9th transistor for the sign, so it is only a mutual agreement on how to read or display the contents of these 8 bits (= 1 byte).

A signed byte covers the range -128 to +127
An unsigned byte covers the range 0 to 255.
However, these bytes are not stored differently in the 8 bits, only their meaning is different for us humans:

Unsigned:
00000000 (Bits) = 0 (Byte)
10000000 (Bits) = 128 (Byte)
11111111 (Bits) = 255 (Byte)

Signed:
00000000 (Bits) = 0 (Byte)
01111111 (Bits) = +127 (Byte)
10000000 (Bits) = -128 (Byte)
11111111 (Bits) = -1 (Byte)

You can see that the values for 255 and -1 are identical in the binary system (11111111). Since a hex editor is rarely expected to display signed hex numbers, you will find only 255 for the -1, of course. But in the file on your hard disk, bytes 255 and -1 are completely identical. It only depends on whether you want to understand an unsigned or signed byte.

Since ReadByte() interprets a byte as an unsigned byte, it cannot return -1. Wait, yes, it can, but it looks like this: 255 ;-)

Kurzer

PS: Try it for yourself with the Windows Calculator in "programmers" advanced mode.

Image
Last edited by Kurzer on Mon Feb 17, 2020 1:51 am, edited 4 times in total.
PB 6.02 x64, OS: Win 7 Pro x64 & Win 11 x64, Desktopscaling: 125%, CPU: I7 6500, RAM: 16 GB, GPU: Intel Graphics HD 520, User age in 2023: 56y
"Happiness is a pet." | "Never run a changing system!"
BarryG
Addict
Addict
Posts: 3292
Joined: Thu Apr 18, 2019 8:17 am

Re: ReadByte/ReadAsciiCharacter return value on error

Post by BarryG »

Thanks for the detailed explanation, Kurzer. I'll also stop now, as I'm not really enjoying myself here.
User avatar
Demivec
Addict
Addict
Posts: 4086
Joined: Mon Jul 25, 2005 3:51 pm
Location: Utah, USA

Re: ReadByte/ReadAsciiCharacter return value on error

Post by Demivec »

BarryG: The return value for all of the Read functions excepting ReadData() have the same issue. My guess as to why an error is returned as a zero value is so that they mirror the way the Write functions operate.

I agree that it is not good for an error condition to be signaled in this way but your solution doesn't address the problem correctly because it wouldn't fix the problem. Puttng kurzer's detailed explanations of bits and byes aside, you could change the output of ReadByte() to be an integer instead of a byte. If there was an error and the value -1 was returned it would be converted to a byte-sized value for a byte-sized variable (or any other size) and still be a valid read value and not distinguishable by itself of an error. Only Ascii and Unicode variable types don't include -1 in their range of values.

It has been suggested that the function could be modified to have an error returned in another variable, i.e. Result = ReadByte(fileID, @error.i).

I think that is doable but I think it could be done one better by providing that variable address when the file is first opened for read/write access or perhaps an additional function that just associates a variable address with a fileID ton get error information for that file. Anybody want to take a crack art a name of such a function, maybe SetFileErrorOutputLocation(@error.i). This would prevent having to change any of the read or write functions calling parameters.

A GetLastFileError(fileID) would also be doable.
User avatar
Tristano
Enthusiast
Enthusiast
Posts: 190
Joined: Thu Nov 26, 2015 6:52 pm
Location: Italy
Contact:

Re: ReadByte/ReadAsciiCharacter return value on error

Post by Tristano »

kurzer wrote:BarryG,Since ReadByte() interprets a byte as an unsigned byte, it cannot return -1.
The PB Documentation regarding ReadByte() presents it as:

Code: Select all

Number.b = ReadByte(#File)
So, because of the .b type of the example, the reader is going to expect that the result would be treated as a signed byte (-128 to +127), as described in Variables and Types.

Of course, if you instead use:

Code: Select all

Number.a = ReadByte(#File)
then you'll end up with an unsigned byte. Possibly, the confusion here regards the term "Byte" in ReadByte(), which some might interpret as the PB native type (and thus expect a signed result), or just as a byte (as in 8 bits, and thus unsigned).

This seems to me one of those topics that you need to experiment with to clear all doubts, which I personally see as a weak point in the documentation — I've lost count of how many hours I had to spent doing trial and errors in order to understand exactly how some PB commands behave. A more clearer documentation, or a few more explicit examples could have spared me those many hours.


I really can't understand why the discussion got so hot at a certain point. The ideal way to resolve doubts is by providing code examples — in this case, a PB source that writes a byte with value 255 to a file, then reads its result directly in a conditional block to check whether it tests positive as an signed or unsigned value.
The PureBASIC Archives: FOSS Resources:
User avatar
Tristano
Enthusiast
Enthusiast
Posts: 190
Joined: Thu Nov 26, 2015 6:52 pm
Location: Italy
Contact:

Re: ReadByte/ReadAsciiCharacter return value on error

Post by Tristano »

Anyhow, here are my tests and their results with the ReadByte() command:

Code: Select all

testVar=255

CreateFile(0, "test")
; Write our var as raw data to file:
WriteData(0, @testVar, 1)

; Let's test reading a byte into a 'Byte' var...
FileSeek(0, 0)
u8.b = ReadByte(0)
Debug "u8 = "+Str(u8) ; -> -1

; Let's test reading a byte into an 'Ascii' var...
FileSeek(0, 0)
i8.a = ReadByte(0)
Debug "i8 = "+Str(i8) ; -> 255

; Let's test how the returned value is interpreted without using vars...
FileSeek(0, 0)
Select ReadByte(0)
  Case -1
    Debug "ReadByte() returned -1" ; <- This is what we get!
  Case 255
    Debug "ReadByte() returned 255"
EndSelect
So, whereas the returned value might be signed or unsigned depending on the type of variable where we store it, if we pass the result of ReadByte() to a branching command it's interpreted as a signed byte.
The PureBASIC Archives: FOSS Resources:
Post Reply