RFC: Simple, safe string library for libgfortran

Janne Blomqvist blomqvist.janne@gmail.com
Wed Jul 25 08:38:00 GMT 2007


Hi,

see the attachments for a proof of concept implementation of a simple 
string library, designed to be safer to use than C strings, while 
remaining compatible with them.

As you may know, a large fraction of security problems and bugs are 
caused by buffer overflows. While Fortran might not be the typical 
language for implementing network-listening daemons running as root, 
buffer overflows are still serious bugs that can be very hard to find. 
As a testament to this, recently a buffer overflow was found in 
libgfortran which had been there for years without being detected. Much 
of this can be attributed to the retarded way strings are represented in 
C, as simply an array of characters with no length information except 
for (hopefully) a null character at the end.

The proposed string library defines a string type, containing a pointer 
to the buffer as well as length information. Also, the typical string 
functions are provided for manipulating strings, with the idea that the 
library takes care of buffer size calculations once and for all.

Note that I haven't tested it very much yet beyond making it compile, so 
  there certainly might be bugs.

Unfortunately, the name 'gstring' was already taken (by Glib) so I 
called it gfstring (GNU Fortran string, if you like).

Comments are welcome. I'm especially interested in

1) There is an asymmetry in the gfstr_alloc and gfstr_init functions; 
alloc creates a string with space for n characters + the null at the 
end, while init has space only for n-1 characters. Is this a problem, 
and should one of them be changed to match the other? The thing is that 
I'd prefer the alloc behaviour, but it's not possible not implement 
cleanly for init (init takes an existing char array as argument).

2) What about Fortran strings, i.e. with no terminating null. Should the 
library rather handle those than C strings, or both? One problem is that 
the library uses the libc vs(n)printf behind the covers, which wants to 
put '\0' at the end of every string (and no, I don't want to reimplement 
vsnprintf). Also, if one wants to use other libc string functions on the 
buffer directly, it better be null terminated.

-- 
Janne Blomqvist
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gfstring.h
Type: text/x-chdr
Size: 1681 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070725/a65be1df/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gfstring.c
Type: text/x-csrc
Size: 1894 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070725/a65be1df/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.c
Type: text/x-csrc
Size: 459 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070725/a65be1df/attachment-0002.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070725/a65be1df/attachment.ksh>


More information about the Fortran mailing list