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