Encoding.GetString

  • Thread starter Thread starter Alcibiade
  • Start date Start date
it's ok, but I'm wondering what the code should do...



Il 14/03/2011 14:42, Arne Vajhøj ha scritto:
 
Il 14/03/2011 14:42, Arne Vajhøj ha scritto:
it's ok, but I'm wondering what the code should do...
Click to expand...

If the code reads 14 bytes, then the should only convert
those 14 bytes to a string not the entire 256 bytes
in the buffer.

Arne
 
Il 14/03/2011 15:29, Arne Vajhøj ha scritto:
If the code reads 14 bytes, then the should only convert
those 14 bytes to a string not the entire 256 bytes
in the buffer.

Arne
Click to expand...

yeah, I think so, instead I get a full lenght string :S
Is this behaviour normal?
 
Il 14/03/2011 15:29, Arne Vajhøj ha scritto:

yeah, I think so, instead I get a full lenght string :S
Is this behaviour normal?
Click to expand...

It is how GetString with 1 and 3 arguments are documented to
work.

Arne
 
Il 14/03/2011 15:29, Arne Vajhøj ha scritto:


yeah, I think so, instead I get a full lenght string :S
Is this behaviour normal?
Click to expand...

If you tell Encoding.GetString() to decode the entire byte[] buffer,
even though you have not received enough bytes to fill the entire
buffer, then you will see the results you are seeing. It is normal to
see those results in that case, but it is not _correct_ for your own code.

In other words, _your_ code has a bug in it. The behavior you are seeing
is normal, given the bug in your code. You need to fix your bug, by
passing to the GetString() method the range of the byte[] buffer you
actually want decoded (i.e. the start index and the length), rather than
just the buffer alone (which will decode the entire buffer).

That's what Arne's original reply to you is saying to do, and it is what
you should do. Once you've done that, you still will get "normal"
behavior from the GetString() method, but that particular "normal"
behavior will be the behavior you want, rather than behavior you don't
want.
Click to expand...

Yes.

But there is a little twist - the code is copied from
the MS docs.

Arne
 
[...]
You told the computer to decode the entire buffer, so that is what it
did. If you had told it to decode only part of the buffer then it
would have done that.
Click to expand...
Well, - go back to the first post, - it is Microsoft, not Arne who made
this error in their example.

http://msdn.microsoft.com/en-us/library/8s4y8aff.aspx#Y1103
Click to expand...

It's true, the networking code examples in MSDN are not very good.
However, it's important to note that that example is for the
Socket.Receive() method, not the Encoding.GetString() method. It does
correctly demonstrate the use of the Socket.Receive() method, albeit in
a context where the rest of the code is not correct.
Click to expand...

How the output from the call should be used is relevant for
the call.
It is a very important skill to have, when reading documentation, to
understand the scope of the documentation and to follow-up with the
actual documentation for any other library or language elements that the
code example might include.
Click to expand...

I would expect the other code in the example to be correct. It may
be necessary to consult the documentation to the see what it does
or to do something differently. But having to consult the documentation
to find out what the code is not correct is absurd.
So, yes…the original documentation being referenced isn't quite right.
Click to expand...

That is an understatement. I would say that it is not right.

Arne
 
Back
Top