[GRASS5] G_string_replace ()?

[Glynn Clements]

Markus Neteler wrote:

> > > > FWIW, for string manipulations (and for OSes not supporting awk just
> > > > provide an already "digest" version) simply use:
> > > > 
> > > > cat old_file | awk 'BEGIN { ORS="<br>";} {print;}' > new_file
> > > 
> > > 
> > > Thierry,
> > > 
> > > thanks for the hint but I need to implement a C solution
> > > in lib/gis/parser.c.
> > 
> > You will have to use the POSIX strstr() function in this case. But may I
> > suggest that, if this is "just" to generate the HTML pages, it will be
> > more easy to implement this using UNIX powertools (sed | awk), providing
> > platforms not having them with a pregenerated tarball?
> 
> In GRASS 5.7 the parser is generating the top part of the
> HTML documentation automated. That's why a C solution is needed.
> It's easy to do in shell, but not applicable here.
> I tired a while to implement it, but got lost with
> pointers, loops and the str* functions.
> 
> Practically I need an extension of 
>  char * G_strchg(char* bug, char character, char new) {
>  /* replace all occurencies of "character" in string(bug) with
>   * "new", returns new string */
> 
> (src/libes/gis/strings.c)
> written by Bernhard. Instead of accepting a single new character 
> insertion of several characters is required.

Which makes the task more complex. A character -> character
substitution can be done in-place, simply overwriting the old
character with the new one. A string -> string substitution may
require moving the subsequent text left or right, depending upon
whether the replacement is shorter or longer than the original.

Also, if the replacement is longer than the original, the new text may
not fit into the original buffer.

The actual algorithm is non-trivial (unlike G_strchg), but isn't
particularly complex. But the memory handling issues have to be
decided first. Viable options include:

1. Passing in the length of the buffer, and either generating a fatal
error or returning an error indication (e.g. NULL pointer) if the
output overflows (the buffer's contents would be undefined).

2. Passing in the length of the buffer; if the text would overflow,
return an error indication, leaving the buffer unchanged. This
requires two passes; one to check the result length without modifying
the buffer, the other to actually perform the changes.

3. Dynamically allocating the result buffer. Either making an initial
guess at the length then reallocating if necessary, or by using two
passes, as in option 2. The program would have to free the result once
it is no longer required.

Regardless of which option is chosen for the allocation of the result
buffer, it is significantly easier if the result is placed in a
separate buffer insted of modifying the source buffer.

-- 
Glynn Clements <glynn.clements at virgin.net>