#if META /* but sadly ontopic */
Although people are perfectly free to post under pseudonyms, a
pseudonym on Usenet seems to be a good indication - not infallible,
just a good indication - that the person using it is a troll.
Han from China (also known as "George Orwell" (and probably "George"
sans surname, too), "Borked Pseudowhatever", and "Anonymous") is an
obvious dishonorable non-exception, as is Kenny McCormack (probably
- it *could*, after all, be his real name). <snip>
'Han' appeared as Orwell, Borked, Anonymous, and Nomen Nescio.
I believe you would be mistaken to include Just-George, who now seems
to have become just-Frank. He(?) has a distinctly different style, and
though recent here has been consistent on c.l.fortran since long
before 'Han'; to my recollection he has never been inflammatory or
vituperative, and rarely even contentious. He does seem a bit loopy*,
and may be worth ignoring on that basis, but not for trollery. (* In
case this word doesn't have the same meaning in en_notUS, it's between
eccentric and mildly crazy; think Elwood P Dowd, the Jimmy Stewart
character in Harvey.) He reminds me a bit of 'chair' (Malbrain).
#endif
And now for something completely different: The Topic!
Trying to salvage this thread may be doomed, but:
Here are some (not necessarily mutually exclusive) ideas that have
been used by stretchy string libraries in the past:
1) "struct hack" - housekeeping data at the front, char array at the
back, allowing stretchy-ready tstrings with a single malloc;
and perhaps pointing to the char part, which makes 'normal' data
accesses more convenient, with negative offsets to the header
2) keeping a max size as well as a current size, allowing the
library to resize when appropriate;
At least using normal C mallocation, realloc may (need to) move, so
that only works if the callers let you modify their pointers, or their
accesses indirect through e.g. a handle table that you can change.
Or just storing the max size without resizing, which still allows
overflow prevention.
3) using start and end pointers rather than a current size;
4) putting sentinels at the beginning and end of the allocated
array, so that buffer overflow - which would indicate a bug in the
library - can (or at least may) be detectable.
IME overrunning the beginning is much rarer than the end.
(And thus less likely worth the cost of checking for.)
For a somewhat unusual application that involved much parsing of
stringy (text) pieces out of a few blobs of data (often only one large
one), I have seen used {ptr,len} all pointing into (and sharing) the
same space, which is deallocated en masse on returning to the top
level. The routines for this were a separate (and separable) module
within the project, but I wouldn't expect it to be widely reusable,
even if it hadn't been proprietary.