[GRASS5] G_string_replace ()?

[Markus Neteler]

On Thu, Mar 11, 2004 at 09:17:30PM +0000, Glynn Clements wrote:
> 
> 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.

A solution is implemented now in src/libes/gis/strings.c thanks
to Beverly Wallace. I have updated the parser in 5.7, now the
HTML pages are rendered smoothly.

Markus