Alternatives to Newlib-Nano?

[nctnico]

I use a global variable so everything stays the same. Another option for redirecting would be to implement fprintf and so on but that could end up being a lot of work.

[Kalvin]

I had a PIC24F project which was required to run on a battery for two-three years, so the energy consumption needed to be reduced as much as possible. I implemented the printf so, that the printf configured the serial port, then printed out the printf arguments, and finally closed the serial port. The closing function took care of waiting until the last character was sent, and then disabled the UART peripheral block.

[legacy]

I don't understand the why? on the why?
you all need to implement that printf things

can't you just implement dedicated functions,
one for each data_type? in ADA style?

out_uint32(string_t msg_head, uint32_t data, string_t msg_tail);
out_sint32(string_t msg_head, sint32_t data, string_t msg_tail);
out_fp32(string_t msg_head, fp32_t data, string_t msg_tail);
out_fx32(string_t msg_head, fx32_t data, string_t msg_tail);

msg_head can be empty "", or "\0", therefore skipped
msg_tail can contain the CR "\n"

from my point of view, it's

• simpler
• safer
• less error prone
• doesn't require any stack manipulation
• consumes less resources

fp32 is for floating point
fx32 is for fixedpoint

they both need some additional work

[Kalvin]

I don't understand the why? on the why?
you all need to implement that printf things

can't you just implement dedicated functions,
one for each data_type? in ADA style?
<snip>

For the convenience mostly. Also, each function call will create some overhead which may be a problem with a MCU with a constrained code memory. I have used the Ada-style print-functions you pointed out in the past, too.

[nctnico]

I don't understand the why? on the why?
you all need to implement that printf things

Simple: printf and (more generally speaking) the C libraries  where invented while the amount of memory available on computers was tiny so they went for the most efficient interface. I have seen people trying to re-invent the wheel many times but in the end the core of printf gets linked in anyway because it is so cleverly constructed.

[legacy]

I have seen people trying to re-invent the wheel many times

it's not a matter of re-inventing the wheel,
it's a matter or mind-set: those C-ish things
are not error-prone, and it's time to move

don't expect to find any printf-like in any avionic product

but in the end the core of printf gets linked in anyway because it is so cleverly constructed.

it doesn't seem "cleverly" constructed at all
in first place it's composed by unsafe code

Code: [Select]

void printf
(
    char *fmt,
    ... <---------------------- this is considered unsafe code


Code: [Select]

    va_list va;
    va_start(va, fmt);
...
    va_end(va);
}
all of these are unsafe code

and crap like the following

Code: [Select]

    *(*((char * *) p))++ = c;

I have just checked with our QA-tool
and it violates 43 rules 


anyway, even considering implementation details
the ADA-like approach does not produce more code
therefore, you actually have choices, so it's only up to you


personally I have already replaced every printf since a while   

[Kalvin]

C as a language is broken anyway, why bother. Yes, you can pretend that C will be a safer with some constructions and limited subset, but nevertheless the C as a language is unsafe.

[legacy]

the C as a language is unsafe.

I agree

here, if someone for some reason needs to use the stack
practically if he or she needs to use va_list, va_start, va_end
and all things defined by stdarg.h, then he or she must classify
the code as "unsafe" and this has the consequence of keeping
more attention from the testing dudes first, and then from the QA
and their acceptance more difficult to be achieved


(if he or she accidentally uses those things without classifying
the code as "unsafe" ... the code will be rejected immediately)

[westfw]

I don't understand the why? on the why?  you all need to implement that printf things

Because it's a considerable aid to program readability to have a sort of "picture" of what your output will actually look like.  Fortran has it, COBOL has it, printf() provides it with C.

can't you just implement dedicated functions, one for each data_type? in ADA style?

And by the time you implement all the different formatting options that people want, how many functions do you have?  Or how many options on each "dedicated" function?  With how much overhead for each option?  Field widths, justification, precision, sign location, leading character choice...

    va_list va;
    va_start(va, fmt);
...
    va_end(va);
}
all of these are unsafe code

Why are these considered so unsafe, when most languages with built-in IO implement plenty of "statements" with variable numbers of arguments, even those languages considered to be much safer than C (Pascal, for example)?  Note that printf() has had strong type checking for its arguments in many C compilers for a decade or so now (much to the chagrin of those who have implemented "custom" versions of printf()...)  A lot of these "QA-tools" seem to be thinking "the way C handled variable numbers of arguments in the distant past was clearly dangerous.   Therefore any modern modification must be dangerous.  Therefore printf() is dangerous no matter how many checks have been added to it..."

[legacy]

Pascal

Pascal does not have it, you need to pass through assembly
ADA does not allow it without passing through the unsafe declaration

printf() has had strong type checking

if you pass the following to some (old) C compiler you will see a crash

Code: [Select]

printf("%s", 0xdeadbeaf);

some old compilers don't actually check it at all, since everything is accepted 
gcc and llvm do some checks, but it's not guaranteed by the "C language"
it's up to the implementation, and it might pass with jus warning shoot

[legacy]

Why are these considered so unsafe, when most languages
with built-in IO implement plenty of "statements"
with variable numbers of arguments

in first place because having variable numbers of arguments in variable size
makes the testing activity more complex, even for debuggers and validators

[legacy]

Code: [Select]

#include <stdio.h>

int main()
{
    printf("%s", 0xdeadbeaf);
    return 0;
}


Code: [Select]

co-nix app # echo "nowarnings" > project.opt.myprj
co-nix app # mygcc-build-project-makefile-v5
co-nix app # make
- generating interface public for app ... done
- generating interface private for app ... done
- linking to my


Code: [Select]

co-nix app # echo "warnings" > project.opt.myprj
co-nix app # mygcc-build-project-makefile-v5
co-nix app # make
- generating interface public for app ... done
- generating interface private for app ... done
- compiling app ... app.c: In function ‘main’:
app.c:5:1: warning: format ‘%s’ expects argument of type ‘char *’, but argument 2 has type ‘unsigned int’ [-Wformat]
done
- linking to my


Code: [Select]

co-nix app # obj/co-nix-mips32r2/my     
Segmentation fault


[nctnico]

Why are these considered so unsafe, when most languages
with built-in IO implement plenty of "statements"
with variable numbers of arguments

in first place because having variable numbers of arguments in variable size
makes the testing activity more complex, even for debuggers and validators

Try and create a versatile formatting function in any language which can do the same as printf and see how testable/verifiable it is.

[legacy]

a good programmer should always remember that
those printf are extremely unsafe constructions.
and those things is that if a formatting specifier
somehow gets inside the string, it will lead to
unpredictable consequences

Try and create a versatile formatting function in any language
which can do the same as printf and see how testable/verifiable it is.

ADA has safe mechanisms to do that, e.g. generic data instantiate
C++ also has something similar, e.g. the use of  "<<" operator

[legacy]

oh, even the Go language has called it "unsafe"
go-static-check/unsafe-printf.go 

[nctnico]

a good programmer should always remember that
those printf are extremely unsafe constructions.
and those things is that if a formatting specifier
somehow gets inside the string, it will lead to
unpredictable consequences

Try and create a versatile formatting function in any language
which can do the same as printf and see how testable/verifiable it is.

ADA has safe mechanisms to do that, e.g. generic data instantiate
C++ also has something similar, e.g. the use of  "<<" operator

I'm not seeing much use of the << in C++ probably due to the lack of formatting. And try to use a non-constant string as a format string... I gave up on that over 15 years ago. GCC won't allow it and goes to great lengths to prevent it.

[westfw]

Pascal does not have it, you need to pass through assembly

huh?  I'm talking about IO support built into the language, not user procedures.  Pascal's standard "read" and "write" procedures support an arbitrary number of arbitrary base-typed arguments.
(I tend to find it particularly annoying when a language defines procedures that permit a syntax that can't be duplicated by user-written procedures.  Though perhaps it is a fine idea from a "safety" perspective. :-(   I think C is one of the first languages where this is rigorously avoided, though I don't know that I've ever seen that expressed as a design goal of the language.  (It used to be common for timesharing system user commands as well; you could do things from the user interface (which was part of the operating system, rather than a separate program) that you could not accomplish from within a user-mode program...)

[langwadt]

C as a language is broken anyway, why bother. Yes, you can pretend that C will be a safer with some constructions and limited subset, but nevertheless the C as a language is unsafe.

soldering irons are unsafe, there is only  limited number of ways you can use one without breaking things or burning you fingers

[legacy]

soldering irons are unsafe, there is only
limited number of ways you can use one
without breaking things
or burning you fingers

is it humor  ?

[Harjit]

Did you end up with an alternative that didn't use dynamic memory? Thanks.

[SiliconWizard]

soldering irons are unsafe, there is only
limited number of ways you can use one
without breaking things
or burning you fingers

is it humor  ?

Irony.
 

[richardman]

It would be interesting to know WHICH C string functions use malloc, because ... they shouldn't and I have difficulty believing that nano-newlib string functions use dynamic memory.

[technix]

It kind of make sense to implement printf using malloc since the resulting string has a undetermined length. If you need to avoid that you can stack or static allocate the memory and snprintf into it, then output it. (All the printf-class functions calls vsnprintf internally, which requires the caller to supply a buffer and its length.)

Code: [Select]

ssize_t printf(const char *format, ...)
{
  va_list args, args2;
  va_start(args, format);
  va_copy(args2, args);
  ssize_t length = vsnprintf(NULL, 0, format, args2);
  va_end(args2);
  if (length > 0)
  {
    char *buffer = malloc(length);
    if (!buffer)
    {
      va_end(args);
      return -1;
    }
    length = vsnprintf(buffer, length, format, args);
    length = fwrite(stdout, buffer, length);
    free(buffer);
  }
  va_end(args);
  return length;
}
   

[rstofer]

When I first start an embedded project, I get the UART working - getc() putc()
Then I grab up "The C Programming Language" (Kernighan & Ritchie) and copy the string and conversion functions.
No heap, simple code, perfect!

I usually build a bunch of layered functions to display (in hex) a nibble, byte, short and int with the '0x' prepended.  I might also use the decimal conversion code - itoa().

To the extent possible, I don't want to use the library code.  Obviously, I can't avoid the C runtime code but I certainly don't need the newlib string functions.

[technix]

It would be interesting to know WHICH C string functions use malloc, because ... they shouldn't and I have difficulty believing that nano-newlib string functions use dynamic memory.

Obviously printf and fprintf (vprintf and vfprintf) use malloc but sprintf and snprintf (vsprintf and vsnprintf) don't. strdup does as per specified by its contract as a chained call of malloc and memmove. Some implementation of sscanf (vsscanf) uses malloc for internal buffers, and if so through that fscanf and scanf (vfscanf and vscanf) will also use malloc.