Forum > Suggestions
ReadBuffer should use out parameter
Handoko:
I suggest using out parameter in TStream.ReadBuffer instead of var.
https://www.freepascal.org/docs-html/rtl/classes/tstream.readbuffer.html
So the example code below won't generate "Buffer" does not seem to be initialized hint for line #10:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---procedure TForm1.Button1Click(Sender: TObject);var Data: TMemoryStream; Buffer: array[0..99] of Byte;begin Data := TMemoryStream.Create; // // .. doing something with the Data // Data.ReadBuffer(Buffer, SizeOf(Buffer)); Data.Freeend;
MarkMLl:
It is a trifle irritating, particularly in view of Doctrine which demands warning-free compilation, but can I suggest a metasolution? What would be really useful would be an instrumented version of the compiler which produced a report of all libraries/packages producing this warning which could be collated and fixed as a single exercise.
After all, each var -> out is a change which, if unsuccessful, will generate a compile error indicating that it should be rolled back.
MarkMLl
wp:
I think this is a good example in which this annoying warning is valid. Suppose you read only a single byte (Stream.ReadBuffer(Buffer[0], 1)) then the buffer would still be uninitialized even if ReadBuffer had an out parameter.
Bart:
And most likely it is Delphi compatible...
And Buffer may be of a managed type, so that might be a problem as well (as is the case for FillChar).
Bart
PascalDragon:
--- Quote from: Bart on May 07, 2021, 12:57:14 pm ---And most likely it is Delphi compatible...
--- End quote ---
Correct. This will not be changed.
Navigation
[0] Message Index
[#] Next page