[A5] al_ustr_empty_string() questions
axilmar

1) Should the result of al_ustr_empty_string() be freed?

2) Is this valid code?

X-G

1)

Quote:

Return a pointer to a static empty string. The string is read only.

2) Valid C, but wrong.

tobing

Shouldn't the return of al_ustr_empty_string(); better be a const ALLEGRO_USTR* then?

X-G

You'd think so, wouldn't you?

tobing

Yes, that's what I would have thought. Or said. Or whatever.

axilmar
Quote:

Return a pointer to a static empty string. The string is read only.

The above is so vague. It can be interpreted in many ways:

  • the string buffer is read only, but the returned Allegro string is not and must be freed.


  • the string buffer is read only, and the returned Allegro string is read only, and so it must not be freed.


  • the string buffer is read only, but the returned Allegro string is not, but even if it is freed, nothing will happen.


  • the string buffer is read only, and the returned Allegro string is read only, and if it is freed, nothing will happen.

I think there is a problem with this function; the returned string should be available to free, since it cannot be shared.

Elias

The return should be const, yes.

axilmar said:

The above is so vague. It can be interpreted in many ways:

Only if you overlook the "static" in there. But yes, always better to be explicit, maybe someone can make a patch which adds something like "The string is read only and must not be freed.".

axilmar

What does 'static' refer to in this context? is the string buffer static or the ALLEGRO_USTR instance static? or both?

Elias

Yeah, as I said, someone should make it more clear. It means both apparently.

Matthew Leverton

When in doubt, look at the source:

utf8.c#SelectExpand
1/* Function: al_ustr_empty_string 2 */ 3ALLEGRO_USTR *al_ustr_empty_string(void) 4{ 5 static struct _al_tagbstring empty = _al_bsStatic(""); 6 return ∅ 7}

GullRaDriel

So it is not thread safe.

X-G

Why wouldn't it be? :P

tobing

Because empty will be initialized by the first caller of al_ustr_empty_string(), and it might happen that two threads try to do this at the same time.

Elias
tobing said:

Because empty will be initialized by the first caller

It's static, it will be initialized before main(). So completely thread-safe.

tobing

It's static, but inside a function. So it's only initialized when the first call to the function occurs.

http://stackoverflow.com/questions/55510/when-do-function-level-static-variables-get-allocated-initialized

bamccaig

Are you sure that isn't just C++? In C, I can't even seem to initialize my static local variable with a function... :-X It needs to be a constant expression (which sounds like compile-time to me). In C++, it's no problem.

Elias

In C static variables (no matter if inside a function or not) are initialized before main().

[edit:]

Found it in the C99 standard, 6.2.4 ยง3:

Quote:

An object whose identifier is declared with external or internal linkage, or with the
storage-class specifier static has static storage duration. Its lifetime is the entire
execution of the program and its stored value is initialized only once, prior to program
startup.

tobing

OK, I'm so much used to C++ that I tend to forget that there might so differences like this. Sorry.

Evert
tobing said:

OK, I'm so much used to C++ that I tend to forget that there might so differences like this.

So does that mean that in C++ code, the compiler has to insert code to check whether a static variable has been used before and is therefore initialised already, or needs to be initialised now? Or does it do code-flow analysis to figure out where to insert the initialisation?
Neither of those sound particularly appealing to me...

tobing

The first. It's checked at runtime if the static is already initialized or not, and the first one coming by does the initialization.

When it comes to overhead and what the compiler generates, I don't know...

The good thing about this is, you can control the initialization, i.e. when the static is initialized. It's quite simple to implement singletons that way, or control the order of initialization of "global" variables between different compilation units.

Thread #606378. Printed from Allegro.cc