But ... do you get to use memcpy() and memset(), or not?
you have there choices
- use what provided by libC (which is included in your toolchain suite, if "it's approved", formally you have "C compiler unit", "assembler unit", "linker unit", "linker script unit", "memory model unit", and "libC unit" (bare metal profiled, of course), "crt0.s unit", all of them MUST be formally approved)
- write your own version of memcpy&C, universal type (which means that you have to force everything to be p_uint8_t/8bit size ---> you need unchecked converter because "casting" is banned)
- write your own versions of $type_memcpy&C
$type_memcpy means you to write
$type={ uint8, uint16, uint32, uint64, char }
for item in $type, do write "$type_memcpy"
(Stood is able to auto build code for you)
Casting is banned, so if you have to force everything to be uint8, you have to use "
unchecked converter"
$type={ uint8, uint16, uint32, uint64, char }
for item in $type, do write "uc_$type_to_uint8(p_$type_t p)
they are functions, written in assembly, under "unsafe code" section
note the prefix "p_" it means "pointer", it's MUST in our conforming code
you could, also, write the full memcopy in assembly, and export it as "unsafe code"
I repeat again: everything is under the name of "unsafe code" MUST be manually checked, justified, and hardly tested twice the twice
and you'd better remember
you are signing with your blood ![Cheesy :D](https://www.eevblog.com/forum/Smileys/default/cheesy.gif)
And what do you do about the compiler's internal use of such functions?
are you kidding ?
![Cheesy :D](https://www.eevblog.com/forum/Smileys/default/cheesy.gif)
we do not have any "collision" with libC (if it's allowed be used): a collision means QAC immediately refuses the code!
Stood & QAC knows everything in the project (formally a project is a collection of modules, each module is collection of items, described by their interfaces)
they know which kind of libC you are using and what is provide by libC (because libC is formally a module, opaque, it means "black box")
You can't redefine a function that is included in libC without getting QAC to stop kicking you on your finger tips!
formally it's a "collision" (public interface collision) with a module!
libC.c ----> libC.interface
exported symbol: memcopy
my_module.c ----> my_module.interface
exported symbol: memcopy
QAC will say something like "ERROR, public collision between libC.interface and my_module.interface: memcopy defined twice"
there is a special attribute "reserved"
libC.interface
exported symbol: memcopy (reserved)
my_module.private
exported symbol: memcopy
"private" is the same as "static" in the C89 language, but … it's used to describe "private" interface (internal C prototypes, QAC uses it as "an attribute" for it's internal data base, there is a data base for each project, because "QAC "MUST be interfaced with "DOORS", which is formally the last suite to be used in order to present a product to QA guys and to the customer)
in this case "memcopy" is a private function, so it "could" overload the libC version, but QAC knows that it's "reserved"
so QAC will say something like "ERROR, public collision between libC.interface and my_module.private: memcopy is reserved, it can't be overloaded"