A string pointer to a static or dynamic string : how to free the dynamic one ?

[R.Wieser]

Hello all,

I'm a rather newbie to C++ programming who is trying figure out how to deal
with string pointers - or rather, with what they point at.

Case in point :

char* message = "hello world";
char* message = strdup("hello world");

I can user either of those in a function and return the pointer, and the
caller will be none-the-wiser which form (the static or dymnamic string) it
gets.

The problem is that the dynamic one needs to be "free"d but tyhe static one
not. How do I look at that "message" pointer whats "in" it so I can take
the correct action.

By the way: the same thing goes for when I want to replace a string. I don't
think that C++ has a garbage-collector running, so I need to do it myself.
:-)

Regards,
Rudy Wieser

[Paavo Helde]

21.01.2023 16:28 R.Wieser kirjutas:
> Hello all,
>
> I'm a rather newbie to C++ programming who is trying figure out how to deal
> with string pointers - or rather, with what they point at.
>
> Case in point :
>
> char* message = "hello world";
> char* message = strdup("hello world");
>
> I can user either of those in a function and return the pointer, and the
> caller will be none-the-wiser which form (the static or dymnamic string) it
> gets.

This is C++, so just return a std::string from your function, and forget
everything about C-style strings, malloc, free and strdup. Good riddance!

[Bonita Montero]

Am 21.01.2023 um 15:40 schrieb Paavo Helde:

> This is C++, so just return a std::string from your function, and forget
> everything about C-style strings, malloc, free and strdup. Good riddance!

And local variables which are top-level variables (f.e. not part of
a pair) are implicitly move constructed. So you won't have to move
the return.

[Richard Damon]

There is no portable way of telling. As others have mentioned,
std:string lets you get around this problem. In a standard
implementation this will copy the static string into the heap, so
std:string knows to always delete its version.

In embedded applications where space may be tight, I use a replacement
version for std::string that looks where the pointer for the string is
coming from, and if it is in system flash, I know it can't change, so I
don't copy it, and inside the string class keep track of that fact.

[Malcolm McLean]

It's a mess, and a hangover from C. C tresats string as character pointers,
and doesn't give you an easy way to tell if they are allocated on the heap, on
the stack, or in read-only memory. So the C programmer has to be careful.

In C++ there is a std::string. Normally when you are using C++, you should make
sure that all strings are turned into std::strings at the earliest opportunity.
Becasue of the magic of destructors, you then needn't worry about the memory the
string points to.
An std::string can be assigned like a variable. Which is frequently useful.
Assignment is relatively expensive because it tends to involve an allocation
and a copy, but it's rare for string assignment to be a time critical step.

[Mut...@dastardlyhq.com]

Unless you want to parse the string which may involve chopping it about. Then
its simpler to use a C string and pointers rather than mess about with
inefficient substr() etc.

[R.Wieser]

"Richard Damon" <Ric...@Damon-Family.org> wrote in message
news:KiTyL.760492$GNG9....@fx18.iad...

> On 1/21/23 9:28 AM, R.Wieser wrote:

>> char* message = "hello world";
>> char* message = strdup("hello world");

...

>> The problem is that the dynamic one needs to be "free"d but tyhe static
>> one
>> not. How do I look at that "message" pointer whats "in" it so I can
>> take
>> the correct action.

> There is no portable way of telling.

I was already afraid of that.

Regards,
Rudy Wieser

[Paavo Helde]

If you want to speed up substring processing, then there is
std::string_view for you. As fast as plain pointers and much cleaner.

[Mike Terry]

As others have said - in C++ we have a string class, which would be the much preferred approach.
Also with resources generally which need to be managed (freed at some point to avoid resource leaks)
the common approach is for those resources to be represented by classes that free the resources when
they go out of scope (or earlier by calling some kind of dispose method).

But this doesn't really answer your question... If you had asked the question in comp.lang.c it
would be more relevant as there is no string class, and the question deserves a literal answer.

The answer is that the documentation for using the function in question needs to clearly specify
whether or not the caller is responsible for freeing particular resources returned by the function.

So perhaps the function documentation might say "Caller is responsible for freeing the returned
string, using free() function". Of course, if you're writing the called function, and want to
return some literal string, you would need to strdup() that literal string yourself, so that it can
be correctly freed by the caller. (The topic is more general than just freeing memory - calls to
the OS often return other resources like handles representing kernal objects, or GUI objects, and
sometimes those resources must be freed by the caller, and sometimes they represent pre-existing
objects owned elsewhere in the system that the caller mustn't free. The whole question of resource
ownership can be troublesome for callers, so the only answer is good documentation. Maybe function
naming conventions like create_xx() vs get_xx() etc. can help, but documentation is the key.

Regards,
Mike.

[Bonita Montero]

Am 21.01.2023 um 17:20 schrieb Mut...@dastardlyhq.com:

> Unless you want to parse the string which may involve chopping it about. Then
> its simpler to use a C string and pointers rather than mess about with
> inefficient substr() etc.

What's wrong with sth. like this ?

string substr()
{
string hw( "hello world!" );
hw.erase( hw.begin(), hw.begin() + 6 );
hw.resize( 5 );
return hw;
}

[R.Wieser]

"Mike Terry" <news.dead.p...@darjeeling.plus.com> wrote in message
news:tPqdnZTbnINss1H-...@brightview.co.uk...

> the question deserves a literal answer.

Thats what I thought too.

> The answer is that the documentation for using the function in question
> needs to clearly specify whether or not the caller is responsible for
> freeing particular resources returned by the function.

My post was more in the direction that /either of/ those string types could
be returned, and I would like to create a "safe release" routine for such a
pointer.

> Of course, if you're writing the called function, and want to return some
> literal string, you would need to strdup() that literal string yourself,
> so that it can be correctly freed by the caller.

Thats good for a simple situation. I was also thinking of a string pointer
which could be initialized by the user but changed by a routine.

Ofcourse, the "you may only provide type 'X' there" documentation rule could
also be applied there. I was just hoping that I could create a bit more
flexibility.

Thanks for the well-aimed reply.

Regards,
Rudy Wieser

[Richard Damon]

So the "string pointer" type you are thinking of needs to be told, and
remember the answer to the question, "Does this memory need to be freed?"

[Mike Terry]

On 21/01/2023 19:09, R.Wieser wrote:
> "Mike Terry" <news.dead.p...@darjeeling.plus.com> wrote in message
> news:tPqdnZTbnINss1H-...@brightview.co.uk...
>
>> the question deserves a literal answer.
>
> Thats what I thought too.
>
>> The answer is that the documentation for using the function in question
>> needs to clearly specify whether or not the caller is responsible for
>> freeing particular resources returned by the function.
>
> My post was more in the direction that /either of/ those string types could
> be returned, and I would like to create a "safe release" routine for such a
> pointer.

A noble aim, but... the C++ and C language raw pointers are basically just "pointers to type xxx"
They don't encapsulate how to free referenced resource(s) - pointers to an object on the stack, or
in static program storage, or on the C/C++ heap or even in the OS process heap will all typically
look similar, i.e. just 32- or 64-bit (or whatever) address space pointer values. You could analyse
the pointer value and try to work out what region of memory it belongs to, but that will be
non-portable and too much to reasonably ask, I'd say.

C++ functions could return some kind of embellished pointer - a class object including the pointer
and also the capability within the class of freeing the referenced resources in various ways
depending on how the resource was created. The embellishment would increase the memory required for
a 'pointer', so this might not be a good idea e.g. if your app might have large arrays of such
pointers. Basically, if there were a /simple/ answer to your original question, there would be no
interesting debate, but there's not - so you need to carefully balance costs/benefits. Simple is
good, unless simple doesn't work! :)

>> Of course, if you're writing the called function, and want to return some
>> literal string, you would need to strdup() that literal string yourself,
>> so that it can be correctly freed by the caller.
>
> Thats good for a simple situation. I was also thinking of a string pointer
> which could be initialized by the user but changed by a routine.

There are two aspects here, and it's good to keep them separate.

Looking at the std::string class, that addresses the "initialized by the user but changed by a
routine" bit of the problem, which I'll suggest is 99% of the benefit you're after. [Pass strings
as std::string& ]

The remaining "I really want to return pointers to memory allocated (and so to be later freed) in
several different ways decided at run-time ALL FROM THE SAME FUNCTION" is a separate problem. It
could be addresed with the approach of embellished pointers. The standard library supports custom
allocators which can serve as template arguments for containers like std::string, so you could have
a std::string with an embellished pointer - but, so much added complexity for what??

If you're more interested in C APIs, using raw pointers etc., then the whole topic of
responsibilities for managing memory between callers and called functions IN GENERAL is quite
subtle. DCE's Remote Procedure Call (RPC) framework has to solve this issue because the calling and
called routines typically are in different address spaces with no shared memory, and it's far from
trivial! The problem is that C/C++ language in itself does not sufficiently describe pointer use to
make this possible. E.g. a pointer could be a REF pointer to a single struct, or to an array, and
structs can chain to other structs, possibly involving loops of pointers, or at least having
multiple pointers to a single struct. Also pointers need to be understood as IN/OUT/INOUT in terms
of which way data is being passed to/from a function, which affects the rules for managing the
memory. If you're interested in the GENERAL solution for this kind of problem the DCE RPC
documentation (or Microsofts DCOM which uses RPC) relating to memory management would at least give
you a good idea of the issues.

But if you just want to provide one C-style API for one function with a modifiable IN/OUT parameter,
just do something like:

int AmendString (/*INOUT*/ char** ppString);

and clearly document callers responsibity, including how the string memory must initially be
allocated by the caller, and how it must eventually be freed upon return.

Mike.

[Keith Thompson]

Malcolm McLean <malcolm.ar...@gmail.com> writes:
[...]

> It's a mess, and a hangover from C. C tresats string as character pointers,

No, a C string is by definition "a contiguous sequence of characters
terminated by and including the first null character". It is not a
pointer.

A *pointer to a string* is by definition "a pointer to its initial
(lowest addressed) character". Most manipulation of strings in C is
done via string pointers.

> and doesn't give you an easy way to tell if they are allocated on the heap, on
> the stack, or in read-only memory. So the C programmer has to be careful.

Right.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[jak]

Il 22/01/2023 01:54, Keith Thompson ha scritto:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> [...]
>> It's a mess, and a hangover from C. C tresats string as character pointers,
>
> No, a C string is by definition "a contiguous sequence of characters
> terminated by and including the first null character". It is not a
> pointer.
>
> A *pointer to a string* is by definition "a pointer to its initial
> (lowest addressed) character". Most manipulation of strings in C is
> done via string pointers.
>
>> and doesn't give you an easy way to tell if they are allocated on the heap, on
>> the stack, or in read-only memory. So the C programmer has to be careful.
>
> Right.
>

pointer to a string? by definition? string pointers? Maybe you are
confusing programming languages. The C language has no string pointers.

[James Kuyper]

On 1/22/23 04:46, jak wrote:
> Il 22/01/2023 01:54, Keith Thompson ha scritto:

...

>> A *pointer to a string* is by definition "a pointer to its initial
>> (lowest addressed) character". Most manipulation of strings in C is
>> done via string pointers.

...> pointer to a string? by definition? string pointers? Maybe you are

> confusing programming languages. The C language has no string pointers.

When he said "by definition", he meant it:

"A _pointer to a string_ is a pointer to its initial (lowest addressed)
character." (C standard (n2731) 7.1.1p1).

The phrase "pointer to a string" is in italics, an ISO convention
indicating that the sentence in which that phrase occurs constitutes the
official definition of the meaning of that term.

[jak]

Il 22/01/2023 11:20, James Kuyper ha scritto:
> On 1/22/23 04:46, jak wrote:
>> Il 22/01/2023 01:54, Keith Thompson ha scritto:
> ...
>>> A *pointer to a string* is by definition "a pointer to its initial
>>> (lowest addressed) character". Most manipulation of strings in C is
>>> done via string pointers.
> ...> pointer to a string? by definition? string pointers? Maybe you are
>> confusing programming languages. The C language has no string pointers.
>
> When he said "by definition", he meant it:
>
> "A _pointer to a string_ is a pointer to its initial (lowest addressed)
> character." (C standard (n2731) 7.1.1p1).
>

"pointer to a string" could be a pointer at the first element of an
array that contains a string, perhaps. You argue a lot about the
definitions contained in the "ISO", perhaps the writers should be
convinced to use greater precision.

[R.Wieser]

"Mike Terry" <news.dead.p...@darjeeling.plus.com> wrote in message

news:OtycnbSNHJxJ_1H-...@brightview.co.uk...

> A noble aim, but... the C++ and C language raw pointers are basically just
> "pointers to type xxx" They don't encapsulate how to free referenced

> resource(s).

:-) That was what I tried to get clear : if perhaps the current iteration of
the language perhaps had such a ... something. An "I'm static" bitflag would
have been enough for my purposes.

> You could analyse the pointer value and try to work out what region of
> memory it belongs to, but that will be non-portable and too much to
> reasonably ask, I'd say.

Athough I currently am way to much of a novice in the language that might
actually be something I would try - even if just to show myself that it
isn't a good idea.

> Simple is good, unless simple doesn't work! :)

Thats something I know as "KISS" ("Keep It Stupidly Simple" / "Keep It
Simple, Stupid") and I quite agree with.

> Looking at the std::string class, that addresses the "initialized by the
> user but changed by a routine" bit of the problem, which I'll suggest is
> 99% of the benefit you're after. [Pass strings as std::string& ]

Using the "document the function!" method you mentioned earlier I could also
tell the user that only dynamic strings are permitted as input.

> It could be addresed with the approach of embellished pointers.

I'm sorry, but currently I have absolutily /no idea/ what those are.

> If you're more interested in C APIs, using raw pointers etc., then the
> whole topic of responsibilities for managing memory between callers and
> called functions IN GENERAL is quite subtle. DCE's Remote Procedure Call
> (RPC) framework has to solve this issue because the calling and called
> routines typically are in different address spaces with no shared memory,
> and it's far from trivial!

You mean marshalling ? I had to do that in Windows (using my preferred
language, Assembly) when I tried to retrieve some data from a control on a
dialog that was part of another process - which included having to "remote
allocate" some memory to copy to/from.

> The problem is that C/C++ language in itself does not sufficiently
> describe pointer use to make this possible.

As above, thart was what I needed to make sure of - before I started to try
to create all kinds of complex-y solutions that would not be needed.

> E.g. a pointer could be a REF pointer to a single struct, or to an array,
> and structs can chain to other structs, possibly involving loops of
> pointers, or at least having multiple pointers to a single struct.

Hey ! I was trying to keep it simple ! :-)

But yes, I was thinking in the same direction. In my case I wanted to
provide and/or return the string as part of a structure. The structure
could be dynamic too, meaning that before the structure would be destroyed
all of the strings in it need to be destroyed first.

> But if you just want to provide one C-style API for one function with a
> modifiable IN/OUT parameter, just do something like:
>
> int AmendString (/*INOUT*/ char** ppString);

Ehhrrmm... I didn't even realize that I needed that notation. I skipped it
that specific notation by having the string pointer "hidden" in a structure.

> and clearly document callers responsibity, including how the string memory
> must initially be allocated by the caller, and how it must eventually be
> freed upon return.

Agreed.

The only problem is that my user is rather stupid. I'm not sure if I'm, at
some time in the future, will be able to use the function I wrote myself
without fouling up and wondering whatever I was thinking of when I wrote it.
:-)

Thanks for the explanation.

Regards,
Rudy Wieser

[R.Wieser]

"Richard Damon" <Ric...@Damon-Family.org> wrote in message

news:bSYyL.44734$%os8....@fx03.iad...

> On 1/21/23 2:09 PM, R.Wieser wrote:

> So the "string pointer" type you are thinking of needs to be told, and
> remember the answer to the question, "Does this memory need to be freed?"

Its unclear to me which "string pointer" you are referring to there : the
result of the strdup() function, or the "char* message" variable it is
stored in.

But yes, that is pretty much what I was asking about - with the "being told"
part done by the programming language. With me just checking what it was
told.

Regards,
Rudy Wieser

[R.Wieser]

"Keith Thompson" <Keith.S.T...@gmail.com> wrote in message
news:87a62bi...@nosuchdomain.example.com...

> A *pointer to a string* is by definition "a pointer to its initial
> (lowest addressed) character".

To disambiguate :

Assuming that a "pointer to a string" is something a function like strdup()
returns, what do you call the (type of) variable that such a result is
stored in ?

... it often confuses the h*ll outof me when the word "stringpointer" is
used for both. :-\


Regards,
Rudy Wieser

[Bo Persson]

On 2023-01-22 at 12:17, jak wrote:
> Il 22/01/2023 11:20, James Kuyper ha scritto:
>> On 1/22/23 04:46, jak wrote:
>>> Il 22/01/2023 01:54, Keith Thompson ha scritto:
>> ...
>>>> A *pointer to a string* is by definition "a pointer to its initial
>>>> (lowest addressed) character".  Most manipulation of strings in C is
>>>> done via string pointers.
>> ...> pointer to a string? by definition? string pointers? Maybe you are
>>> confusing programming languages. The C language has no string pointers.
>>
>> When he said "by definition", he meant it:
>>
>> "A _pointer to a string_ is a pointer to its initial (lowest addressed)
>> character." (C standard (n2731) 7.1.1p1).
>>
>
> "pointer to a string" could be a pointer at the first element of an
> array that contains a string, perhaps.

No, not "perhaps", but definitely. The term "pointer to a string" IS a
pointer to the first element of an array that contains a string. That's
what it says.

There are other pointers that can point to a char that is not part of a
string. Those are then not "pointer to a string".

[Öö Tiib]

A pointer to a string is (constrained in described way) pointer to a
character. So variable has to be of type pointer to a character.

[jak]

ISO standard can cancel that definition because the C does not have
strings but only an agreement that allows the functions to use array as
strings.

[Paavo Helde]

22.01.2023 12:56 R.Wieser kirjutas:
> "Mike Terry" <news.dead.p...@darjeeling.plus.com> wrote in message
> news:OtycnbSNHJxJ_1H-...@brightview.co.uk...

>> You could analyse the pointer value and try to work out what region of
>> memory it belongs to, but that will be non-portable and too much to
>> reasonably ask, I'd say.
>
> Athough I currently am way to much of a novice in the language that might
> actually be something I would try - even if just to show myself that it
> isn't a good idea

This is basically impossible. Yes, maybe you can tell on some platform
if a string pointer points to some address in the heap, stack or a
global static area. Alas, even if it points to heap, you still won't
know if you may or must call free() on the pointer. The string might be
allocated globally and meant to be in shared use for longer, or the
string might be a part of another data structure which your code doesn't
even know how to deallocate.

So it's not just a bad idea, but impossible, unless you want to severely
cripple the ways how strings may be used in your program.

>
>> Simple is good, unless simple doesn't work! :)
>
> Thats something I know as "KISS" ("Keep It Stupidly Simple" / "Keep It
> Simple, Stupid") and I quite agree with.

If you want to keep it simple, then just use C++ std::string, you can't
get simpler than that, unless switching over to Python(*) or something.

(*) Some might claim Python strings are actually more complicated than
in C++ because of codepage/unicode nuances, Python 2 / Python 3
differences, and hidden performance gotchas, e.g. the computational
complexity of Python string += operation is worse in Python than in C++.

[Paavo Helde]

ISO standard defines what C is or is not. It's not up to a random
internet commenter.

Of course ISO standard committee can change the wording in the next
version. If they do this and drop the definition of the term "pointer to
a string" from the next C standard, then C will not have such thing any
more. But until then it does.

[David Brown]

Exactly.

A "string" is "a contiguous sequence of characters terminated by and
including the first null character", as defined by the C standards and
therefore by C (for those that don't understand how the language is
defined).

So a "pointer to a string" is also a "pointer to character", though
pointers to characters do not necessarily point to strings. And since
there is no specific type for a "string" in C, you use "pointer to
character" types to hold "pointer to string" values.

[R.Wieser]

"嘱 Tiib" <oot...@hot.ee> wrote in message
news:604d1f9c-51b9-4e7d...@googlegroups.com...

Thats not what I ment. If an address which is pointing to a sequence of
characters is called a "pointer to a string" - normally referred to as "a
string pointer" - , what should the variable which stores that addres be
called ?

Regards,
Rudy Wieser

[R.Wieser]

"Paavo Helde" <ees...@osa.pri.ee> wrote in message
news:tqjaaa$33tcp$1...@dont-email.me...

> 22.01.2023 12:56 R.Wieser kirjutas:
>> "Mike Terry" <news.dead.p...@darjeeling.plus.com> wrote in
>> message
>> news:OtycnbSNHJxJ_1H-...@brightview.co.uk...

>>> Simple is good, unless simple doesn't work! :)
>>
>> Thats something I know as "KISS" ("Keep It Stupidly Simple" / "Keep It
>> Simple, Stupid") and I quite agree with.
>
> If you want to keep it simple, then just use C++ std::string, you can't
> get simpler than that, unless switching over to Python(*) or something.

I'll keep that in mind. Heck, I might even go and take a look at it some
time. :-)

Regards,
Rudy Wieser

[jak]

The comments are feedback. Feedback helps. Faith sometimes kills.

[jak]

... I thought about what happens in the Middle East. Faith is faith and
the laws are laws but what is written is not always right.

[Richard Damon]

On 1/22/23 9:40 AM, R.Wieser wrote:
> "Öö Tiib" <oot...@hot.ee> wrote in message

A pointer to string (with type pointer to char).

Just like an int value (like 5) is the value of a given bit combination,
a variable that holds such a value is also called an int.

If you need to distinguish them, one is a value, and the other is a
variable (or object)

[Richard Damon]

Excpet that it DOES have strings, as defined in &.1.1p1

A string is a contiguous sequence of characters terminated by and

[Keith Thompson]

Note that we're talking about C; C++, the topic of this newsgroup, is a
related but distinct language.

What C calls a "string" is very close to (probably identical to) what
C++ calls a "null-terminated byte string", or NTBS. The informal term
"C-style string" is common, to distinguish it from C++'s std::string.

In C, there is no string type (unless you define one yourself). The
language-defined term "string" is used to refer to a data format, not a
data type. An object of type "array of char" may or may not contain a
string (or multiple strings).

The C term "pointer to a string" is not analogous to, for example,
"pointer to an int". It is a language-defined phrase because the term
"pointer to a string" either would not make sense or would have a
different meaning in the absence of that definition. A pointer to a
string points to the initial (0th) element of the string, and can be
used via array arithmetic, indexing, and calls to library functions to
manipulate the string.

An object containing a *pointer to a string* is normally of type char*
or const char*.

Everything that can be done in C using C-style strings and C-style
string pointers can be done the same way in C++, but it's almost
always easier and safer to use std::string.

To answer your original question, given a char* value (say, a function
parameter), neither C nor C++ gives you a way to determine how the
memory it points to was allocated, and therefore how and whether it
should be deallocated. If you want to pass pointers around and let the
called function decide whether and how to deallocate it, you'll have to
pass that information somehow, probably as another argument or by
wrapping the pointer in a structure or class. Note also that memory
allocated by malloc() should be deallocated by calling free(), and
memory allocated by new should be deallocated by delete; mixing the two,
IIRC, has undefined behavior.

But again, std::string takes care of all of this for you.