Size of buffer pointed to by char* returned from field_buffer

Question

So I am trying to work with the <form.h> library provided by <ncurses>

I am reading this man page that tells me of the function:

char *field_buffer(const FIELD *field, int buffer);

The return type is a pointer to char *. On the end of this pointer, I suspect, is a c-style array containing the chars I want to access. Now I can use this function cautiously and try to not overstep when reading out the data (it returns all chars saved in a field, so I suppose not looping past the field size is a cautious approach). But is there no way for me to know the size of the buffer pointer to by char *?

I only now this way to read out the data:

char *ptr = fiel_buffer(someField, 0);
size_t dontKnow = 100; //if I had the underlying array arr I would do dontKnow = sizeof(arr) / sizeof(arr[0]
for (size_t i = 0; i < dontKnow; i++)
   std::cout << ptr[i] << std::endl;

Answer 1

It's not explicitly stated, but since there's no pointer to a length-parameter allowing the library to return the string-length as a side-effect, you have the C convention of null-terminated strings.

The manpage does say this:

The function field_buffer returns a pointer to the contents of the given numbered buffer:

• The buffer contents always have the same length, and are padded with trailing spaces as needed to ensure this length is the same.
• The buffer contents are set with set_field_buffer, or as a side effect of any editing operations on the corresponding field.

and

The function set_max_field sets the maximum size for a dynamic field.

(dynamic fields are mentioned in another manpage, form_field_info).

Actually that "always the same length" applies to the number of columns used for the field. If you have stored a multibyte string (UTF-8), the number of bytes is not necessarily the same for each buffer. The source for field_buffer is the place to read for details like that.

The original SVr4 manpages were less informative — see Solaris for example (and the tutorials in the reference manuals not much better).