Byte comparison in Oxygene

Elements Oxygene
#1

I have a Byte comparison failing in Oxygene that was really confusing me. The byte being read in is a paragraph marker in MacRoman encoding, byte value 166. I was reading this into a Byte, which displayed in the debugger as -90 due to the signing issue. I created a byte var to represent the paragraph marker

const kParagraphMarker = chr(166); // actually defined elsewhere in codebase
var paragraphMarker := Byte(kParagraphMarker);

This also displays in the debugger as -90, but when I do a comparison (aByte = paragraphMarker) the comparison fails. I tried casting to Char and one was 166 while the other was 65k. When I cast to Integer both are 166.

It occurred to me that this could be something similar to Java’s primitive wrappers, where int is a primitive and Integer is a wrapper object for it, so the = operator is actually a reference comparison rather than a value comparison, which may fail unpredictably due to internal caching mechanisms. So I tried aByte.equals(paragraphMarker) and it worked correctly.

I have byte comparisons throughout my codebase that use the = operator. These operations previously worked and now do not. Is this an intended change? If so, is there a way around it without having to find and change all of my byte comparisons using the = operator? (I have many, many of these in my codebase as there are a lot of low-level text/char operations)

#2

I think too this should be the default behaviour but until some of the RO teammember says smth, you could write:

ByteExt = public record extension(Byte)
  operator Equal(const value: Byte):  boolean;
  begin
      exit self.Equals(value);
  end;
end;
1 Like
#3

Great idea, I forget that Oxygene allows operator functions. Thanks!

2 Likes
#4

Hm, could you create asnall testcase that shows this (ideally with just number literals, no actual file reading)?

its n to an intended change, but Java is weird, in that “byte” is our own unsigned type, but “java.lang.Byte” is unsigned, so depending on whats exactly in scope where, this could cause confusion. I’d like to have the compiler team have a look at concrete case where this happens…

#5

I had difficulty reproducing it, but that revealed the root cause. Seems like an interop issue between Elements byte and java byte.

  var javaByte: java.lang.Byte := 166; // {-90}

  var byte1 := Byte(javaByte); // -90
  var byte2: Byte := 166; // -90

  var char1 := Char(byte1); // #65446
  var char2 := Char(byte2); // #166

  var opEqual := (byte1 = byte2); // false
  var funEqual := (byte1.equals(byte2)); // true
1 Like
#6

Thanks, logged as bugs://85394

#8

FTR,

  var byte1 := Byte(javaByte); // -90
  var byte2: Byte := 166; // -90

these both prints as 166, not as -90. Burt regardless, the = seems to fail, yes.

#9

The -90 is what it shows in the debugger when I inspect them. I didn’t actually try to print if that’s what you mean, so the inspection could be an unrelated bug.

1 Like
#10

I’d say thats a separate bug, even; if debugger and writeLn don’t match l)

1 Like
#11

Thanks, logged as bugs://85418

#12

bugs://85394 got closed with status fixed.

#13

bugs://85418 got closed with status fixed.

#14

bugs://85418 got reopened — possible regression, see Java Byte interpretation on 10.0.0.2595 - #2 by mh

#15

bugs://85418 got closed with status fixed.