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

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.

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.

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.


Cheers,

Isaac



Em 15/04/2025 17:31, smplx escreveu:
>
>
> On Tue, 15 Apr 2025, Isaac Marino Bavaresco wrote:
>
>> Hi folks,
>>
>> I was thinking about the current discussion about C/C++ language 
>> safety, and I recalled an old idea I had long ago about creating a 
>> new string format and library.
>>
>> It could be possible for one person alone to implement and use it 
>> privately, but of course it would be even better if it becomes a 
>> standard, perhaps with support from the compilers.
>>
>> I don't know whether something similar was already suggested or is 
>> being used, but I would like to know your opinion about it.
>>
>
> Hi Isaac,
>
> Really sorry to rain on your parade but nothing you do will ever make 
> C/C++ strings safe.
>
> The problem is that no mater how you craft your libraries, the 
> complier is not aware of the fundamental properties of a string so a 
> pointer to a string will never feedback info to the compiler and the 
> compiler will therefore never be able to compensate for pointer misuse.
>
> Consider two fundamental common operations on a string:
> (1) appending data to a string
> (2) scanning a string character by character
>
> In (1) it is often necessary to increase the size of the string. This 
> involves allocating a new memory area on the heap (often using 
> realloc). This sometimes causes old pointers to be invalidated - they 
> point to sections of the heap which have been freed while the grown 
> string has been copied to a new section of the heap.
>
> In (2) a pointer is slowly moved along a string while each character 
> of the string is processed. Maybe a specific character is being search 
> for. What happens if the string suddenly changes size or is moved to a 
> new heap position? The pointer will become rouge and could cause all 
> kinds of damage. We get the argument that a string cannot suddenly 
> move. Actually this is a VERY real danger. What happens if two of more 
> threads access the same string at the same time? Can't happen? What 
> about the main line and an interrupt handler? What about a function 
> calling another function with a string it is actualy using? The child 
> function modifies the string, the string gets realloced and the parent 
> function is now (sometimes) left procesing a freed section of memory.
>
> The only way you are ever going to have safe strings is if the 
> compiler can track their use and generate extra code depending on how 
> it sees they are being used.
>
> Just my 2 cents worth.
>
> Friendly Regards
> Sergio Masci

-- 
O software antivírus Avast realizou uma checagem de vírus neste e-mail.
www.avast.com

-- 
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
https://mailman.mit.edu/mailman/listinfo/piclist