Inspecting some of my "C" source code here I noticed a construct that
I dislike...

static char buf[32]; // sufficient space for ansi sequence
...
sprintf (buf, "\033[38;5;%dm%c\033[0m", ...);

In case of known or deducible string sizes I'm preferring and using
some of the alloc() functions. In the sample I can at least deduce an upper-bound for the buffer-size. But it's anyway still an undesired
hard-coded buffer size that I'd like to avoid.

I recall that in C++ I used "String-Streams" for dynamically extended
strings. But in "C" my reflex (and habit) is to write things like the
above code.

Is there something in "C" that allows dynamic flexibility of strings?
(Or are there other options that an experienced "C" programmer would
use instead?)

(If there's something available only with newer C-standards I'd also
appreciate a hint.)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 19 Dec 2024 02:30:18 +0100, Janis Papanagnou wrote:

Is there something in "C" that allows dynamic flexibility of strings?

As usual, standard C is pretty boring in this regard. And as usual, POSIX offers something a bit more.

<https://manpages.debian.org/3/open_wmemstream.3.en.html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The ‘asprintf’ subroutine is standardized by POSIX.1-2024, meaning that
you can use it now and blame somebody else if it doesn't work. If you
can't target POSIX, the subroutine is also _theoretically_ available
through the feature-test macro ‘__STDC_WANT_LIB_EXT2__’, assuming that ‘__STDC_ALLOC_LIB__’ is a predefined macro, but gLibC does not pay attention to that for this subroutine, and which feature-test macro does
induce its declaration is seemingly undocumented, though it is at least
defined through ‘_DEFAULT_SOURCE’.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

Inspecting some of my "C" source code here I noticed a construct that
I dislike...

static char buf[32]; // sufficient space for ansi sequence
...
sprintf (buf, "\033[38;5;%dm%c\033[0m", ...);

snprintf is much safer for cases like this, as it will detect
overflow and terminate the formatting before overrunning the buffer.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 19 Dec 2024 19:47:28 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-12-19, BlueManedHawk <bluemanedhawk@invalid.invalid> wrote:

The ‘asprintf’ subroutine is standardized by POSIX.1-2024, meaning
that you can use it now and blame somebody else if it doesn't work.
If you

Regardless of how it is made visible, you can detect it via a compile
test in a configure script, and provide your own if it wasn't found:

#if !HAVE_ASPRINTF

int asprintf(char **out, const char *fmt, ...)
{
... // more or less trivial to implement using malloc, realloc and
vsprintf

Don't you mean, vsnprintf ?

}

#endif

BTW, is there no wchar_t version of this?

can't target POSIX, the subroutine is also _theoretically_
available through the feature-test macro ‘__STDC_WANT_LIB_EXT2__’, assuming that ‘__STDC_ALLOC_LIB__’ is a predefined macro, but gLibC does not pay

When would it be the case that you can't target POSIX, but *can* mess
around with some the internal feature test macros of some specific
POSIX vendor? :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-19, BlueManedHawk <bluemanedhawk@invalid.invalid> wrote:

The ‘asprintf’ subroutine is standardized by POSIX.1-2024, meaning that you can use it now and blame somebody else if it doesn't work. If you

Regardless of how it is made visible, you can detect it via a compile
test in a configure script, and provide your own if it wasn't found:

#if !HAVE_ASPRINTF

int asprintf(char **out, const char *fmt, ...)
{
... // more or less trivial to implement using malloc, realloc and
vsprintf
}

#endif

BTW, is there no wchar_t version of this?

can't target POSIX, the subroutine is also _theoretically_ available
through the feature-test macro ‘__STDC_WANT_LIB_EXT2__’, assuming that ‘__STDC_ALLOC_LIB__’ is a predefined macro, but gLibC does not pay

When would it be the case that you can't target POSIX, but *can* mess
around with some the internal feature test macros of some specific POSIX vendor? :)


--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-12-19, Michael S <already5chosen@yahoo.com> wrote:

On Thu, 19 Dec 2024 19:47:28 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-12-19, BlueManedHawk <bluemanedhawk@invalid.invalid> wrote:

The ‘asprintf’ subroutine is standardized by POSIX.1-2024, meaning
that you can use it now and blame somebody else if it doesn't work.
If you

Regardless of how it is made visible, you can detect it via a compile
test in a configure script, and provide your own if it wasn't found:

#if !HAVE_ASPRINTF

int asprintf(char **out, const char *fmt, ...)
{
... // more or less trivial to implement using malloc, realloc and
vsprintf

Don't you mean, vsnprintf ?

That detail will become obvious when you try to implement it.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19.12.2024 02:30, Janis Papanagnou wrote:

[...]

Thanks for the various suggestions and hints. I've got an idea
what's possible and what I'll buy with each option. That's very
useful information.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 19 Dec 2024 22:06:09 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-12-19, Michael S <already5chosen@yahoo.com> wrote:

On Thu, 19 Dec 2024 19:47:28 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-12-19, BlueManedHawk <bluemanedhawk@invalid.invalid>
wrote:

The ‘asprintf’ subroutine is standardized by POSIX.1-2024,
meaning that you can use it now and blame somebody else if it
doesn't work. If you

Regardless of how it is made visible, you can detect it via a
compile test in a configure script, and provide your own if it
wasn't found:

#if !HAVE_ASPRINTF

int asprintf(char **out, const char *fmt, ...)
{
... // more or less trivial to implement using malloc, realloc
and vsprintf

Don't you mean, vsnprintf ?

That detail will become obvious when you try to implement it.

It sounds like Janis would prefer different API.

struct string_buffer {
char* ptr;
size_t len;
size_t cap;
};
int append_printf(struct string_buffer*, , const char *fmt, ...);

Implementation is as trivial as asprintf.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 19 Dec 2024 23:14:17 -0300
Thiago Adams <thiago.adams@gmail.com> wrote:

Em 12/19/2024 7:06 PM, Kaz Kylheku escreveu:

On 2024-12-19, Michael S <already5chosen@yahoo.com> wrote:

On Thu, 19 Dec 2024 19:47:28 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-12-19, BlueManedHawk <bluemanedhawk@invalid.invalid>
wrote:

The ‘asprintf’ subroutine is standardized by POSIX.1-2024,
meaning that you can use it now and blame somebody else if it
doesn't work. If you

Regardless of how it is made visible, you can detect it via a
compile test in a configure script, and provide your own if it
wasn't found:

#if !HAVE_ASPRINTF

int asprintf(char **out, const char *fmt, ...)
{
... // more or less trivial to implement using malloc, realloc
and vsprintf

Don't you mean, vsnprintf ?

That detail will become obvious when you try to implement it.

I did on implementation in 2020 (not using it)

http://thradams.com/vadsprintf.html

You mean, you don't use asprintf() that you implemented?
That's understandable. The API is rather badly designed. Can be handy
in toy examples, less so in production software.

The standard should have a string stream compatible with FILE because
- differently of asprintf - if cannot be implemented separately.

What level of compatibility?
IMHO, the level that makes sense is where compatibility excludes
fopen, fclose and fflush. I.e. you have new functions, mem_fopen()
and mem_fclose() and do not allow fflush(). Pluse, you add few more
functions or macros for direct access to buffer.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Dec 2024 08:32:24 -0300
Thiago Adams <thiago.adams@gmail.com> wrote:

A function printing in a FILE* fprint also should be able to print in
a string stream.

Of course.
But I don't like your naming and semantics implied by the name.
It should be memory buffer stream rather than string stream.
I.e. zero characters should be allowed in the middle, zero termination
not guaranteed, fwrite and fputc should work as expected etc...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Dec 2024 08:32:24 -0300, Thiago Adams wrote:

For my needs a string stream is better I am using this https://github.com/thradams/cake/blob/main/src/osstream.c Unfortunately
it is not compatible with FILE*.

As usual, standard C is pretty boring in this regard. And as usual, POSIX offers something a bit more.

<https://manpages.debian.org/3/open_wmemstream.3.en.html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)