Re: [EE] Ideas about improving safety in C language

On Fri, 18 Apr 2025, Isaac Marino Bavaresco wrote:

> Hi Sergio,
>
>
> The problem you mention in (2) is not related to strings or any other 
> data structure in particular, but to threads themselves. And for that, 
> there are measures to solve or mitigate them. In short, if data is being 
> corrupted by another thread, then the programmer messed up by not using 
> a mutex or other mechanism.

Hi Isaac,

No you've missunderstood.

Any function can be considered a form of thread but every thread cannot be 
considered a function. By considering functions as threads I am reducing 
the amount of work necessary to discuss the problem. When function FOO 
invokes function BAR, function BAR can be described as a thread that is 
launched by function FOO. FOO prepares the context within which BAR 
executes and then launches it. Often BAR will run to completion before FOO 
resumes, sometimes BAR will continue asynchronously and run concurrently 
with FOO. If FOO invokes a mutex on a string that BAR needs to modify then 
a deadlock will most likely occure.

Consider:

BAR(char *str, int pos, char *stuff)
{
 	int	len1, len2, j;

 	len1 = strlen(str);

 	len2 = strlen(stuff);

 	str = realloc(str, len1 + len2 + 1 - 1);

 	// make space at pos
 	for (j=len1+len2; j>pos+len2; j--)
 	{
 		str[j] = str[j-1];
 	}

 	// insert 'stuff' at pos
 	for (j=0; stuff[j]!='\0'; j++)
 	{
 		str[pos+j] = stuff[j];
 	}
}


FOO(char *str, char *stuff)
{
 	int	j;

 	for (j=0; str[j]!='\0'; j++)
 	{
 		if (str[j] == '@')
 		{
 			BAR(str, j, stuff);

 			// at this point str might have been moved
 			// but the pointer str will not have been
 			// updated
 		}
 	}
}

For the above 'str' to be safe, there needs to be a string structure 
(descriptor) that is independent of the string "payload" such that the 
payload can be moved about in memory while the descriptor does not move 
and the individual characters within the string are always accessed using 
the desciptor (lingering pointers to char are prohibited). This would 
require the compiler to understand when a pointer to char is actually a 
pointer to a char within a string.

I have actually done some work on this in XCSB v3 but ill health has made 
this a sporadic project.

>
> The problems I was referring to are the ones you mention in (1), that 
> is, problems pertaining to string manipulation specifically. Standard C 
> library functions are unsafe (they do not check maximum length of the 
> destination string, for instance). It is possible to implement better 
> functions that take the size of the destination string as an argument 
> (they do exist, see 'strlcat', for instance), but the programmer can 
> always pass a wrong size by mistake.
>
> What I'm suggesting is a completely new data type, that besides the 
> characters themselves it stores information about maximum length, 
> current used length, etc. and that is manipulated in the same way it is 
> done for the present standard strings.

I would strongly recommend that you break the string into 2 parts, the 
string descriptor and the string payload. That way you can keep the 
descriptor in a constant location while the payload hops around.

In C++ you could actually operload the "[]" operator but good luck getting 
programmers to NOT short circuit this with "char *ptr".

>
> Of course it is not possible to have a 100% transparent and seamless 
> implementation without the compiler's awareness (that is, implement the 
> new strings in the language standard), but a fairly good solution could 
> be created by just creating a new library.

I wish you good luck

Friendly Regards
Sergio Masci