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

[Christian JULLIEN]

> 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 againsta libtcc.dll. Am I right?

Right!

I've no precise idea why tcc.c requires pstrcpy:
$ grep strcpy tcc.c
            pstrcpy(child_path, sizeof child_path - 40, argv[0]);
            strcpy(child_name, target);
        pstrcpy(buf, sizeof(buf), target);
        pstrcpy(ext, sizeof(buf) - (ext-buf), ".d");
    pstrcpy(buf, sizeof(buf), name);
        strcpy(ext, ".dll");
        strcpy(ext, ".exe");
        strcpy(ext, ".o");
        strcpy(buf, "a.out");

I see it uses both pstrcpy and strcpy.

----- message d'origine -----
De : "Jean-Claude Beaudoin" <address@hidden>
date lun. 26/09/2016 07:48 (GMT +02:00)
À : "address@hidden" <address@hidden>
Objet : Re: [Tinycc-devel] Tidying TCC's external API

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?

 

_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel