Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34480 > unrolled thread

OutputStream.write(int)

Back to article view | Back to comp.lang.java.programmer

Contents

  OutputStream.write(int) v_borchert@despammed.com (Volker Borchert) - 2016-06-05 22:54 +0000
    Re: OutputStream.write(int) Jan Burse <janburse@fastmail.fm> - 2016-06-06 01:45 +0200
      Re: OutputStream.write(int) v_borchert@despammed.com (Volker Borchert) - 2016-06-06 03:19 +0000
        Re: OutputStream.write(int) Jan Burse <janburse@fastmail.fm> - 2016-06-06 11:58 +0200
          Re: OutputStream.write(int) v_borchert@despammed.com (Volker Borchert) - 2016-06-06 15:51 +0000
    Re: OutputStream.write(int) Arne Vajhøj <arne@vajhoej.dk> - 2016-06-05 20:09 -0400
    Re: OutputStream.write(int) Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2016-06-05 19:38 -0700

#34480 — OutputStream.write(int)

The javadoc as of 1.8 states: "The 24 high-order bits of b are ignored."
Are they really? I.o.w., has anybody encountered broken implementations
that don't, and where?

	vb


-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [next] | [standalone]

#34481

Hi

Well, its a byte stream. I doubt that you can convey something
in the higher 24-bits in some implementation.

At least we can say that 0x000000 and 0xFFFFFF must be ignored,
otherwise the default implementation of write(byte[],..) gets
broken:

     public void write(byte b[], int off, int len) throws IOException {
	if (b == null) {
	    throw new NullPointerException();
	} else if ((off < 0) || (off > b.length) || (len < 0) ||
		   ((off + len) > b.length) || ((off + len) < 0)) {
	    throw new IndexOutOfBoundsException();
	} else if (len == 0) {
	    return;
	}
	for (int i = 0 ; i < len ; i++) {
	    write(b[off + i]);
	}
     }

But an Outputstream might also overwrite this method, it is
not a final method. But most likely we want:

      write(x)                      does the same as
      write(new byte[]{(byte)x})

And the above invariant wouldn't hold if we were to interpret
the upper 24-bits.

Bye

Volker Borchert schrieb:
> The javadoc as of 1.8 states: "The 24 high-order bits of b are ignored."
> Are they really? I.o.w., has anybody encountered broken implementations
> that don't, and where?
>
> 	vb
>
>

[toc] | [prev] | [next] | [standalone]

#34486

Jan Burse wrote:

> At least we can say that 0x000000 and 0xFFFFFF must be ignored,
> otherwise the default implementation of write(byte[],..) gets
> broken:

I can see 0x000000, but not 0xffffff. And I'd be more suspicious
about <0 vs. >=0 than about intermediate bits.

> But an Outputstream might also overwrite this method, it is
> not a final method. But most likely we want:
> 
>       write(x)                      does the same as
>       write(new byte[]{(byte)x})
> 
> And the above invariant wouldn't hold if we were to interpret
> the upper 24-bits.

Good point. But I'd think that he who intentionally violates the
general contract might not care about that either.

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [prev] | [next] | [standalone]

#34489

Volker Borchert schrieb:
> I can see 0x000000, but not 0xffffff. And I'd be more suspicious
> about <0 vs. >=0 than about intermediate bits.

byte is a signed data type. if you accesse a byte array
element you get an int value in the range -128 to 127.
The statement in write(byte[],..) where this happens is this:

        write(b[off + i]);

[toc] | [prev] | [next] | [standalone]

#34498

Jan Burse wrote:
> Volker Borchert schrieb:
> > I can see 0x000000, but not 0xffffff. And I'd be more suspicious
> > about <0 vs. >=0 than about intermediate bits.
> 
> byte is a signed data type. if you accesse a byte array
> element you get an int value in the range -128 to 127.
> The statement in write(byte[],..) where this happens is this:
> 
>         write(b[off + i]);

Ich werde hundertmal schreiben: Nicht vor dem Aufwachen posten.

	vb

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [prev] | [next] | [standalone]

#34483

On 6/5/2016 6:54 PM, Volker Borchert wrote:
> The javadoc as of 1.8 states: "The 24 high-order bits of b are ignored."
> Are they really? I.o.w., has anybody encountered broken implementations
> that don't, and where?

Well an OutputStream is byte centric, so I would expect it to ignore
the high part.

If one need to truly output binary int, then one need to use
DataOutputStream (or NIO).

Arne

[toc] | [prev] | [next] | [standalone]

#34485

In article <nj2ajp$4h$1@Gaia.teknon.de>,
 v_borchert@despammed.com (Volker Borchert) wrote:

> The javadoc as of 1.8 states: "The 24 high-order bits of b are ignored."
> Are they really? I.o.w., has anybody encountered broken implementations
> that don't, and where?
> 
> 	vb

Nope.  It must eventually become a byte so it would be difficult to not 
truncate the bits.

Accidentally converting a byte to int with sign extension while reading 
is more common.

-- 
I will not see posts from astraweb, theremailer, dizum, or google
because they host Usenet flooders.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web