On Wed, 2003-02-12 at 19:01, CBFalconer wrote:
"Richard D. Jackson" wrote:
... snip ...
So the question is how can you assign the capacity to a String type when you are returning it from a function? I would prefer to not have to make a type for this if possible.
Just think about functions in general. What are you going to do with the values they return? In general, you will store them in a variable, which must have a type that can receive that function result. To have two (or more) things of the same type it is necessary to declare that type.
True but it seems gpc does not enforce this. For instance lets say:
type str255 = String (255);
var myStr : String (100);
function foo: Str255; begin ... end;
begin myStr := foo; ... end.
In this case what gpc does is truncate the return value to fit into myStr. Other words this does not cause a compiler error so the compiler sees these two strings as being equivlant even though that is not the case. The question I have is WriteLn just reading String.Length and only ouputing that amount of data or is String.String actualy constrained to 255. If you look below you will see why I wonder that.
On Wed, 2003-02-12 at 19:34, Frank Heckenbach wrote:
So the question is how can you assign the capacity to a String type
when
you are returning it from a function? I would prefer to not have to make a type for this if possible.
You'll have to do exactly this, I'm afraid. E.g., the `GPC' unit defines a type `TString' which it uses for all string function results.
Also while on the subject of strings are gpc strings protected against buffer overruns?
Modulo possible bugs, yes. (But I don't know if anyone has run extensive tests, so if you want to do this, I'll try to fix any bugs you might find ...)
What is interesting is that. Given
var buff : String (255);
I can stuff 30925 chars into it after that majic number I get a segfault. So what is happening here? If I suround a string with other vars they are not getting overwriten wich is a good thing but I still wonder why it did not segfault at 256. I guess it is something I will have to look into when I have more time to dig into it with gdb.
Richard