Re: [Tinycc-devel] Tidying TCC's external API

[grischka]

Jean-Claude Beaudoin wrote:
> On Mon, Sep 26, 2016 at 1:04 AM, Christian Jullien <address@hidden> wrote:
>
> > In order to build tcc.c on Windows, I reverted pstrcpy back to a PUB_FUN.
> >
> >
> >
> > Hope it’s also Ok for you.
>
> I gather that this is for the case where ONE_SOURCE is "not" set,
> and under a "configure --disable-static" such that tcc is linked against
> a libtcc.dll. Am I right?
>
> Even in that situation it should strike as odd that only pstrcpy of all
> functions
> seem to need such a special status. I'd rather say that it is the special
> definition of PUB_FUNC on Windows that needs further investigation.
> In order to bring the situation on Windows on a par with the unix one,
> I think we should rethink the default definition of ST_FUNC such that
> it would better follow the one of PUB_FUNC. What do you say?

At the time it was introduced, PUB_FUNC were all the functions not listed
in libtcc.h (LIBTCCAPI)  but still required by the tcc.c compiler front-end.
A kind of "extended API" for tcc itself if you want to.

Since then some stuff was moved from tcc.c to libtcc.c (for example the
whole option parser), which is why tcc now requires less of that
"internal access".

If it's only pstrcpy then you might as well replace it by _snprintf, for
example.

-- gr