PureBasic Forums - English

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.

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.

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.

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.

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.

Thanks for the detailed explanation, Kurzer. I'll also stop now, as I'm not really enjoying myself here.

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.

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

The PB Documentation regarding ReadByte() presents it as:
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:
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.

Anyhow, here are my tests and their results with the ReadByte() command:
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.