AVR Freaks

Presumably you are saying that the terminal shows "Test6969" then just stops?

is %lf valid with avr-libc?

https://www.microchip.com/webdoc/AVRLibcReferenceManual/group__avr__stdio_1gaa3b98c0d17b35642c0f3e4649092b9f1.html

I suspect that the conversion specifier system does not know how to use floats in the place of doubles.

update: a key word was missing

The way he's  using malloc should be OK as there's only one thing allocated and then freed after use each time. But it does kind of raise the question of why not simply use a global "scatchpad" buffer allocated by the linker.

BTW #1 and then my simulator quest that mimicked it just used %f, not sure where %lf sprang from?

Heap fragmentation, memory leaks, and heap exhaustion are a few of the problems you can run into when using dynamic memory allocation in an embedded system if you aren't careful. In many cases, including yours, you can avoid dynamic memory allocation if you spend a little more time at the drawing board.

In your application you should be able to determine a reasonable upper bound for the length of the strings generated by your conversions at compile time. You could then modify the signatures of ConvertIntToStr() and ConvertDblToStr() to make the caller responsible for providing the buffer the conversion is stored in, but at that point you might as well just have the callers call snprintf() directly. The buffers could be allocated on the stack by the callers of snprintf(), or they could be a global "scrathpad" buffer as clawson suggested. If a global buffer is used there is no need to pass the storage to the conversion functions since they could access it directly, but you would need to be extremely careful about the lifetime of anything placed in the buffer.

C99 added support for stack allocated variable-length arrays which can be used as an alternative to dynamic memory allocation. C11 made support for stack allocated variable-length arrays optional.

Some notes on your code:

• Dynamically allocating memory and then using the result of the allocation without ensuring it succeeded is an extremely bad practice.
• When using the printf() family of functions with fixed-width integer types, you should be using the format specifier macros provided in inttypes.h, not the format specifiers for built-in types. Since int16_t happens to be int with avr-gcc (so long as you aren't using the option that makes int 8-bit), you happen to not encounter any problems. If GCC's -Wformat warning is enabled (enabled by -Wall), the compiler will check for format string errors.

Could an ARM M0 use the avr-libc shrink style of printf?

https://packages.debian.org/buster/libnewlib-nano-arm-none-eabi

That is interesting.

https://keithp.com/newlib-nano/

I found that while fishing for clues why %f might work, but %lf might not. Now back on subject, I know %f works (epccs is my github)

https://github.com/epccs/RPUno/blob/master/Adc/analog.c#L98

but I did have to turn on floats printing (forgot about that) with

https://github.com/epccs/RPUno/blob/master/Adc/Makefile#L53

I am not set up at the moment to try %lf.

Or just:

char* str = malloc( 20 );

and see if that works. (I predict it will as I'm guessing that David is right and the limited version of snprintf() in avr-libc may not have this NULL/Len=0 option.

EDIT: yup, this is the AVR implementation of snprintf():

http://svn.savannah.gnu.org/viewvc/avr-libc/trunk/avr-libc/libc/stdio/snprintf.c?revision=1944&view=markup

I see nothing there to handle the NULL/Len=0 case - it's just assuming 's' is a valid pointer and n is a valid length.

vfprintf source is here:

http://svn.savannah.gnu.org/viewvc/avr-libc/trunk/avr-libc/libc/stdio/vfprintf.c?revision=2191&view=markup

There are two implementations of the function. The libprintf_flt.a one has the PRINTF_FLT handling from about line 370 onwards. 

Remember that on entry to this the only indication not to output is stream->size = -1. I personally cannot see anything there handling this as a special case. 

The only use I see made of the .stream field in the FILE structure is back in snprintf() itself where it does:

        if (f.size >= 0)
63	                s[f.len < f.size ? f.len : f.size] = 0;

IOW it only writes a terminating zero is size is zero or postitive. But this seems to be the only use of the -1 that has been put there.

Actually I don't see anything in the implementation that is policing the N in sprintf(buff, N, ...) at all ?? The implication would seem to be that the length field is actuall superfluous in snprintf() and you might as well just use sprintf(). 

Off to try a simulator experiment to try and overflow a buffer...

void foo(int n) {
    char buff[n];
}

I just test built:

void foo(char * str) {
	int i;
	char buff[strlen(str)];
	for (i = 0; i < strlen(str); i++) {
		buff[i] = str[i];
	}
}

and it certainly seems to compile OK. Haven't tried using it yet though.

EDIT: with sufficient volatile applied that works just fine. One thing that surprised me is that with strlen() in the for() loop it really does thoe whole strlen() every time - I thought it would cache the result but it doesn't so best to force this manually:

void foo(char * str) {
	int i, len;
	volatile char buff[strlen(str)];
	len = strlen(str);
	for (i = 0; i < len; i++) {
		buff[i] = str[i];
	}
}

malloc(), calloc(), and realloc() can fail to allocate memory. When they do fail, they return a null pointer which you must check for and handle. Dereferencing a null pointer results in undefined behavior.

• In the case of writing to a dereferenced null pointer, you are overwriting whatever happens to be at the address a null pointer points to (likely address 0 but this can vary depending on the implementation) which will almost certainly lead to your running program exploding at some point in the future.
• In the case of reading from a dereferenced null pointer, you may be reading memory that doesn't contain the type/value you expect which could lead to your running program exploding at some point in the future.

Writing to and reading from dangling pointers pose the same dangers. Calling free() on a pointer that has already been freed or on a pointer that was not returned by malloc(), calloc(), or realloc() can also cause your running program to explode at some point in the future.

Format specifiers for fixed width integer types are defined in inttypes.h. These should always be used when working with fixed width integer types since you do not know a fixed width type's underlying built in type. If you use the built in format specifiers for a type that ends up being promoted to int/unsigned int, this ends up not actually mattering. However, in cases where an assumed promotion does not occur (such as an implementation where int_fast8_t is actually long) you will get unexpected behavior. A compiler can catch these kinds of format string mismatches if the appropriate warnings are enabled.

The following example checks for memory allocation failures, and makes use of fixed width integer type format specifiers. The snprintf() failure checks are generally overkill (or at least better done with assert() or something with similar behavior) since failures are usually (always?) due to misuse, some of which can be caught by the compiler if the appropriate warnings are enabled.

char * convert_int16_t_to_string( int16_t number )
{
    int buffer_size = snprintf( NULL, 0, "%" PRId16, number ) + 1;
    if ( buffer_size <= 0 ) {
        return NULL;
    } // if

    char * string = malloc( buffer_size );
    if ( !string ) {
        return NULL;
    } // if

    if ( snprintf( string, buffer_size, "%" PRId16, number ) < 0 ) {
        free( string );

        return NULL;
    } // if

    return string;
}

Georg-Johann, your contributions to this compiler are incredible. It's making this a really great tool. What a shame if it's deprecated at V10 and removed at V11!

void XBeeSendInt(int16_t number)
{
    char temp[20]; // 20 should be more than enough in all cases!!
    char* str = temp;

    snprintf( str, 20, "%" PRId16, number );
    while(*str)
    {
        XBeeSendChar(*str++);
    }
}

or perhaps more generally:

char reusable_buffer[32];

void XBeeSendInt(int16_t number)
{
    char* str = reusable_buffer;
    snprintf( str, 32, "%" PRId16, number );
    while(*str)
    {
        XBeeSendChar(*str++);
    }
}

Then reuse the same global/shared buffer wherever you have the need for a temporary thing holding up to 32 bytes.

The advantage of the global is that it's allocate by the linker at build time so you'll know immediately if there's a RAM shortage. With the local it's going to depend on dynamic RAM/stack usage at the time.

Data encapsulation should always be a goal in modular (maintainable!) software. But, yeah, in resource limited micros it's not unusual to have some kind of general "scratchpad" buffer that you share across several tasks. One could envisage some kind of lock/free mechanism around such a buffer if you wanted to protect it from dual use. (so user has to get a lock (mutex?)) first before they can use it) if you were really worried.