Re: [Tinycc-devel] Tinycc-devel Digest, Vol 132, Issue 22

[Josip Habjan]

Thanks, this is exactly what I was looking for. It will be nice for the user to be able to deploy a single dll with everything in it for a C scripting inside their .NET applications.

Cheers,

jhabjan

2014-04-16 18:00 GMT+02:00 <address@hidden>:

Send Tinycc-devel mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.nongnu.org/mailman/listinfo/tinycc-devel
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tinycc-devel digest..."


Today's Topics:

   1. Re: dynamic library - embedded header, object,
      library....files (Domingo Alvarez Duarte)
   2. Re: dynamic library - embedded header, object,
      library....files (Jared Maddox)


----------------------------------------------------------------------

Message: 1
Date: Tue, 15 Apr 2014 20:09:16 +0100
From: Domingo Alvarez Duarte <address@hidden>
To: address@hidden
Subject: Re: [Tinycc-devel] dynamic library - embedded header, object,
        library....files
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

That is just what I did here https://github.com/mingodad/tinycc I called it
virtual_io.

If you checkout it and execute the script "mk-it" it will create a self
contained tinycc, the same principle can be used to use it as a library.

Cheers !


On Tue, Apr 15, 2014 at 4:58 PM, Josip Habjan <address@hidden> wrote:

> Hi,
>
> Is there a chance to add a simple function that will allow users to load
> all required files from memory? For instance: I made a .NET wrapper for
> tcclib and I have all 'lib' and 'include' files compiled in a single .NET
> dll as embedded resources. Now, I don't want to export embedded files out
> from the dll to disk, and then run compiled, instead i would like compiler
> to ask me where he can find requested file. (In my case I want it to be
> read from memory).
>
> What I'm thinking is some function that will allow file redirection. This
> would be easy for non windows systems which supports "fmemopen" function as
> they can easily redirect some file request to the file descriptor from
> memory returned by "fmemopen". For windows users the only option is a
> memory buffer.
>
> What I had in mind is something like:
>
> typedef struct RedirectedFile
> {
> int fd;
> void *buf;
>  unsigned long buflen;
> unsigned char filename[1024];
> } RedirectedFile;
>
> LIBTCCAPI void tcc_set_file_redirection_func(TCCState *s,
> int(*get_file_func)(const char *filename, RedirectedFile *rf),
> void(*release_file_func)(void* buff, int fd));
>
> typedef struct FileOrBuffer
> {
> int state;
> int is_fd;
> int fd;
>  void *buf;
> unsigned long len;
> unsigned long pos;
>  int is_redirect;
> } FileOrBuffer;
>
> typedef struct BufferedFile {
> ...   FileOrBuffer fob;  /* ex: int fd */
>     ...
> } BufferedFile;
>
> and then in tcc_open before opening a file I would simply call
> "get_file_func"...
>
> I know this takes a lot of changes for all file reads and seeks, but..
> actualy, it's not that complicated as I had to replace and add only 2
> functions:
>
> PUB_FUNC int tcc_fobread(FileOrBuffer *fob, void *dest, int size)
> {
> if (fob->is_fd)
> return read(fob->fd, dest, size);
> else {
>  long available = fob->len - fob->pos;
>
> if (size > available) {
> size = available;
>  }
>
> memcpy(dest, (char*)fob->buf + fob->pos, size);
>
> fob->pos += size;
>
> return size;
> }
> }
>
> PUB_FUNC long tcc_foblseek(FileOrBuffer *fob, long offset, int origin)
> {
> if (fob->is_fd)
> return lseek(fob->fd, offset, origin);
> else {
>  long pos;
> switch (origin) {
> case SEEK_SET: {
>  if (offset >= 0) {
> pos = offset;
> }
> else {
>  pos = 0;
> }
> break;
> }
>  case SEEK_CUR: {
> if (offset >= 0 || -offset <= fob->pos) {
> pos = fob->pos + offset;
>  }
> else {
> pos = 0;
> }
>  break;
> }
> case SEEK_END: {
> pos = fob->len + offset;
>  break;
> }
> default:
> return -1;
>  }
>
> if (pos > fob->len) {
> return -1;
>  }
>
> fob->pos = pos;
> return pos;
>  }
> }
>
> C is not really familiar to me, I'm more .NET oriented, but I gave it a
> try and came up with the solution. Here is a complete source code that
> works:
>
> https://www.dropbox.com/s/4y30qrejkmocvqn/tcc-src.zip
>
> Thanks,
> jhabjan
>
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/tinycc-devel/attachments/20140415/920f86de/attachment.html>

------------------------------

Message: 2
Date: Wed, 16 Apr 2014 00:15:36 -0500
From: Jared Maddox <address@hidden>
To: address@hidden
Subject: Re: [Tinycc-devel] dynamic library - embedded header, object,
        library....files
Message-ID:
        <CABXS6_=address@hidden>
Content-Type: text/plain; charset=UTF-8

Happily, it appears that the cat did NOT send this email for me.

> Date: Tue, 15 Apr 2014 17:58:57 +0200
> From: Josip Habjan <address@hidden>
> To: address@hidden
> Subject: [Tinycc-devel] dynamic library - embedded header, object,
>         library....files
> Message-ID:
>         <CABA7v=address@hidden>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> Is there a chance to add a simple function that will allow users to load
> all required files from memory? For instance: I made a .NET wrapper for
> tcclib and I have all 'lib' and 'include' files compiled in a single .NET
> dll as embedded resources. Now, I don't want to export embedded files out
> from the dll to disk, and then run compiled, instead i would like compiler
> to ask me where he can find requested file. (In my case I want it to be
> read from memory).
>
> What I'm thinking is some function that will allow file redirection. This
> would be easy for non windows systems which supports "fmemopen" function as
> they can easily redirect some file request to the file descriptor from
> memory returned by "fmemopen". For windows users the only option is a
> memory buffer.
>

Look up "virtual io tcc", or look at this (
http://lists.nongnu.org/archive/html/tinycc-devel/2013-01/index.html )
page, starting around January 10th. I don't believe such a facility
was ever accepted into a release candidate, but I think it was on a
"not enough requests" basis rather than anything else. Then again, I
didn't review all of those emails.

On a slightly separate note, this is the second question that seemed
relevant to "virtual io" that I REMEMBER from as many weeks (the other
was in a direct email). I think that there really is enough reason to
add this sort of "glue layer" into TCC, though I also wonder if this
should be forcibly delayed until after the "globals removal" work has
been completed and merged, since it would probably be wise to allow
individual states to be associated with individual individual IO
wrappers.



------------------------------

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


End of Tinycc-devel Digest, Vol 132, Issue 22
*********************************************