Author Topic: Alternatives to Newlib-Nano?  (Read 11828 times)

0 Members and 1 Guest are viewing this topic.

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17866
  • Country: nl
    • NCT Developments
Re: Alternatives to Newlib-Nano?
« Reply #25 on: October 06, 2016, 08:14:45 am »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 1788
  • Country: fi
  • Embedded SW/HW.
Re: Alternatives to Newlib-Nano?
« Reply #26 on: October 06, 2016, 09:08:31 am »
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.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4302
  • Country: ch
Re: Alternatives to Newlib-Nano?
« Reply #27 on: October 06, 2016, 09:30:06 am »
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
« Last Edit: October 21, 2018, 11:24:23 am by legacy »
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 1788
  • Country: fi
  • Embedded SW/HW.
Re: Alternatives to Newlib-Nano?
« Reply #28 on: October 06, 2016, 11:54:28 am »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17866
  • Country: nl
    • NCT Developments
Re: Alternatives to Newlib-Nano?
« Reply #29 on: October 06, 2016, 01:11:46 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4302
  • Country: ch
Re: Alternatives to Newlib-Nano?
« Reply #30 on: October 06, 2016, 01:36:19 pm »
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  :palm: :palm: :palm:


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   :-//

 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 1788
  • Country: fi
  • Embedded SW/HW.
Re: Alternatives to Newlib-Nano?
« Reply #31 on: October 06, 2016, 01:39:25 pm »
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.
« Last Edit: October 06, 2016, 01:45:30 pm by Kalvin »
 
The following users thanked this post: MarkL

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4302
  • Country: ch
Re: Alternatives to Newlib-Nano?
« Reply #32 on: October 06, 2016, 02:13:36 pm »
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)
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3047
  • Country: us
Re: Alternatives to Newlib-Nano?
« Reply #33 on: October 06, 2016, 09:37:16 pm »
Quote
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.

Quote
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...

Quote
    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..."
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4302
  • Country: ch
Re: Alternatives to Newlib-Nano?
« Reply #34 on: October 06, 2016, 10:43:44 pm »
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
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4302
  • Country: ch
Re: Alternatives to Newlib-Nano?
« Reply #35 on: October 06, 2016, 10:59:28 pm »
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

 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4302
  • Country: ch
Re: Alternatives to Newlib-Nano?
« Reply #36 on: October 06, 2016, 11:09:15 pm »
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
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17866
  • Country: nl
    • NCT Developments
Re: Alternatives to Newlib-Nano?
« Reply #37 on: October 06, 2016, 11:13:36 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4302
  • Country: ch
Re: Alternatives to Newlib-Nano?
« Reply #38 on: October 06, 2016, 11:46:23 pm »
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

 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4302
  • Country: ch
Re: Alternatives to Newlib-Nano?
« Reply #39 on: October 06, 2016, 11:49:15 pm »
oh, even the Go language has called it "unsafe"
go-static-check/unsafe-printf.go  :-DD
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17866
  • Country: nl
    • NCT Developments
Re: Alternatives to Newlib-Nano?
« Reply #40 on: October 07, 2016, 12:17:07 am »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3047
  • Country: us
Re: Alternatives to Newlib-Nano?
« Reply #41 on: October 07, 2016, 09:49:13 am »
Quote
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...)
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 1498
  • Country: dk
Re: Alternatives to Newlib-Nano?
« Reply #42 on: November 07, 2016, 11:14:13 pm »
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
 
The following users thanked this post: nugglix

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4302
  • Country: ch
Re: Alternatives to Newlib-Nano?
« Reply #43 on: November 08, 2016, 06:12:38 pm »
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  :D ?
 

Offline Harjit

  • Regular Contributor
  • *
  • Posts: 75
  • Country: us
Re: Alternatives to Newlib-Nano?
« Reply #44 on: October 19, 2018, 05:50:38 pm »
Did you end up with an alternative that didn't use dynamic memory? Thanks.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 3474
  • Country: fr
Re: Alternatives to Newlib-Nano?
« Reply #45 on: October 19, 2018, 06:44:26 pm »
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  :D ?

Irony.
 ;D
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Alternatives to Newlib-Nano?
« Reply #46 on: October 20, 2018, 02:50:38 am »
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.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3219
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Alternatives to Newlib-Nano?
« Reply #47 on: October 20, 2018, 04:42:10 am »
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;
}
   
« Last Edit: October 20, 2018, 05:37:46 am by technix »
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 6536
  • Country: us
Re: Alternatives to Newlib-Nano?
« Reply #48 on: October 20, 2018, 03:26:16 pm »
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.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3219
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Alternatives to Newlib-Nano?
« Reply #49 on: October 20, 2018, 06:03:38 pm »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf