And actually, there's another potential issue here: even if my
suggestion was correct, how can I tell that the implementation
of memset which I provide doesn't end up requiring memset?
or that tomorrow it still won't require memset?
Basically, tcc expects a stand alone implementation of memset
wh
Thanks. I was going by the official gcc docs. I did not test
what it requires beyond those mem* implementations.
Back to tcc, the current help for nostdlib is:
> -nostdlib do not link with standard crt and libraries
Would that be fair to change it to something like:
> -nostdlib do not link wit
On 11.09.2023 14:41, avih via Tinycc-devel wrote:
But in the case of tcc, it's not documented, and seems to go
quite a bit further than what gcc requires
libgcc.a from mingw-gcc-6.3.0 is 6218 kB, all full with according
to your standards "undocumented" stuff that however gcc surely
will require
The issue is bigger than just memset. I found at least 5 more functions
which are required in some cases, not all of them part of stdlib, and I'm
guessing sure there are more, depending on the platform. For instance:
// test3.c ---
typedef struct { int a, b; } S;
void _start(void) {
On 2023-09-10 15:13, Страхиња Радић wrote:
What is weird is that tcc requires a libc function, memset, when none
is
explicitly requested, when for example this code:
It is not that weird I think. Early versions of GCC generates a call to
memset()
as well when zeroing a block of memory [1]
On 23/09/09 08:41PM, david.k...@libertysurf.fr wrote:
> The stdlib is just a glue/wrapper to the underlying operating system, here
> Windows or Linux.
What is weird is that tcc requires a libc function, memset, when none is
explicitly requested, when for example this code:
//---
Hi,
I think you got it all wrong, please reread how a compiler work.
The stdlib is just a glue/wrapper to the underlying operating system, here
Windows or Linux.
But what about an embedded/osless environment ? You provide your own stdlib in
that case.
Hence TCC's purpose is not to provide its
