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>
I don't understand the why? on the why?
you all need to implement that printf things
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.
void printf
(
char *fmt,
... <---------------------- this is considered unsafe code
va_list va;
va_start(va, fmt);
...
va_end(va);
}
all of these are unsafe code *(*((char * *) p))++ = c;
the C as a language is unsafe.
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?
va_list va;
va_start(va, fmt);
...
va_end(va);
}
all of these are unsafe code
Pascal
printf() has had strong type checking
printf("%s", 0xdeadbeaf);
Why are these considered so unsafe, when most languages
with built-in IO implement plenty of "statements"
with variable numbers of arguments
#include <stdio.h>
int main()
{
printf("%s", 0xdeadbeaf);
return 0;
}
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
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
co-nix app # obj/co-nix-mips32r2/my
Segmentation fault
Why are these considered so unsafe, when most languages
with built-in IO implement plenty of "statements"
with variable numbers of argumentsin 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.
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 consequencesTry 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
Pascal does not have it, you need to pass through assembly
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
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 ?
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;
}
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.