Question re. FCL's ssockets unit, "Buffer" type

[Curt Carpenter]

In the FCL ssockets unit I find two methods in the TSocketStream class:

Code: Pascal  [Select][+][-]

1.      Function Read (Var Buffer; Count : Longint) : longint; Override;
2.      Function Write (Const Buffer; Count : Longint) :Longint; Override;    
3.  

     

I'm trying to understand the type of "Var Buffer" and "Const Buffer" here, and have had no luck tracking it down. Can anyone point me in the right direction?  Is it declared explicitly somewhere that I just haven't found?

[ojz0r]

I dont know where its defined, and correct me if im wrong but TInetSocket seems to use the function Read/Write from TSocketStream and that Buffer is a Byte array.

[Thausand]

I'm trying to understand the type of "Var Buffer" and "Const Buffer" here, and have had no luck tracking it down. Can anyone point me in the right direction?  Is it declared explicitly somewhere that I just haven't found?

Type is no type 

That mean can be every thing that want have. But, as write ojz0r when send is byte. Then can be important byte-order of type > byte. https://www.freepascal.org/docs-html/ref/refsu70.html

If look documentation https://www.freepascal.org/daily/packages/fcl-net/ssockets/tsocketstream.html then see is parent THandleStream. Handlestream documentation here https://www.freepascal.org/docs-html/rtl/classes/thandlestream.html,.

Read method have:
Read overrides the Read method of TStream. It uses the Handle property to read the Count bytes into Buffer
If no error occurs while reading, the number of bytes actually read will be returned.

Write method have:
Write overrides the Write method of TStream. It uses the Handle property to write the Count bytes from Buffer.
If no error occurs while writing, the number of bytes actually written will be returned.

If socketstream not have same then is mandatory for write documentation (but documentation not say then is assume byte).

[Curt Carpenter]

Thank you for the link and the explanation Thausand!  I did not know that.   I will have to do some experimenting to figure out where to go from here. 

[jamie]

That is what you call an Un-typed parameter which means you can pass just about anything to it but, the body of the function really needs to know what's doing because you can access memory out-side the realm of things.

 SO, for example, I could give it a Byte,Word, Dword, QWord Record, an Object, or just about anything of any size of anytype.

 For this to happen, things are normally passed around via a pointer, especially the VAR version you would need some sort of size indicator what is what the second parameter is for.

I suppose you could of just used a (var data:pointer....)
 
but then, each time you called the function you would need to give it an address reference to the item you are entering.

The compiler does this for you if you use the Un-Typed parameter.

The Const version would be the same except it follows the CONST rules.

Jamie.

[Khrys]

For those coming from C++, untyped parameters are essentially  void&  (for  var)  or  const void&  (for  const)  parameters (which are forbidden in C++); all you get is a non-Nil  address.

Another strange thing about untyped parameters is that if the buffer you're trying to pass comes as an untyped  Pointer,  you'll have to do what looks like dereferencing a generic/void pointer, which is... weird, to say the least:

Code: Pascal  [Select][+][-]

1. function memmove(Destination, Source: Pointer; Count: SizeUInt): Pointer; cdecl;
2. begin
3.   Move(Source^, Destination^, Count); // The only context where it's possible to do `Pointer^`!
4.   Result := Destination;
5. end;

[tetrastes]

Nothing weird, this is Sparta pascal. 
If you don't dereference pointers passed to Move, they will be pointer to pointer.
And they are not necessarily untyped pointers.

[PascalDragon]

For those coming from C++, untyped parameters are essentially  void&  (for  var)  or  const void&  (for  const)  parameters (which are forbidden in C++); all you get is a non-Nil  address.

Well... it is possible to pass a Nil-value

Code: Pascal  [Select][+][-]

1. SomeProc(PLongInt(Nil)^)

Yes, that is supported.

[440bx]

For those coming from C++, untyped parameters are essentially  void&  (for  var)  or  const void&  (for  const)  parameters (which are forbidden in C++); all you get is a non-Nil  address.

Well... it is possible to pass a Nil-value

Code: Pascal  [Select][+][-]

1. SomeProc(PLongInt(Nil)^)

Yes, that is supported.

Which is unfortunate because one of the functional purposes of "var" is to ensure a nil value cannot be passed and the above "trick" violates that.

[creaothceann]

That trick can also be used to suppress compiler warnings, for example when clearing stack variables with FillChar.

[Khrys]

Well... it is possible to pass a Nil-value

Code: Pascal  [Select][+][-]

1. SomeProc(PLongInt(Nil)^)

Hey, no cheating! 

If you don't dereference pointers passed to Move, they will be pointer to pointer.

Yes, and I consider that a footgun (and an insidious one at that):

Code: Pascal  [Select][+][-]

1. // I fell for it again just yesterday!
2. // Also ensure {$H+} for maximum destruction.
3. FillChar(Indent, SPACE_COUNT, ' ');