tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] tcc_relocate() and tcc_relocate_ex()


From: Sean Conner
Subject: Re: [Tinycc-devel] tcc_relocate() and tcc_relocate_ex()
Date: Mon, 3 Sep 2012 17:19:17 -0400
User-agent: Mutt/1.4.1i

It was thus said that the Great grischka once stated:
> Michael Matz wrote:
> >You earnestly added this interface abomination to avoid exporting a 
> >function?    Well, as you asked: yes it's ugly, and yes it's 
> >confusing.  (and it's also non-C, ((void*)-1) might not be 
> >representable; the only integer literal that definitely is convertible 
> >into a pointer is 0; but I'll admit that this would just be a nitpick).  
> >But why you think this interface would be better than an explicit one 
> >with two functions is a complete mystery to me.  I mean, really, can you 
> >give a reason?  I'm seriously interested.
> 
> So you seriously wanted to export the wrapper AND its subroutine?
> I mean, after all, an API is an abstraction layer and not a
> self-service store.

  It depends on how you view APIs.  Under Unix, there are four system calls
to read from a socket:

        ssize_t read(int fh,void *buf,size_t count);
        ssize_t recv(int s,void *buf,size_t count,int flags);
        ssize_t recvfrom(int s,void *buf,size_t count,int flags,struct sockaddr 
*from,socklen_t *fromlen);
        ssize_t recvmsg(int s,struct msghdr *msg,int flags);

  Each give a different level of control over how data from the socket is
read, from "I don't really care" (read()) to "I want total control"
(recvmsg()).  Sure, read recv() probably calls recvfrom(), which in turn
calls recvmsg() [1] and I, for one, like the ability to pick and choose the
level of abstraction I'm comfortable with.  For TCP connections, read() is
good enough, while for UDP, recvfrom() might fit what I'm doing better, and
if I'm implementing OSPF [2] I will most likely use recvmsg().

  Yes, it appears to be a self-service store, but as Joel Spolsky has
stated, "all abstractions leak" [3] and if that's the case, I want to pick
where the leaks are (so to speak).  

> Anyhow, I think it is not more complex/ugly/confusing than the
> alternative.  We would need to show users:
>  - the "abomination" just minus the TCC_RELOCATE_AUTO part
>  - plus the declaration of tcc_relocate + usage comment
>  - some hint at least how the two functions relate to each other
> 
> So, my reasons, short version: Smaller libtcc.h

  Seriously?  *That's* your argument?  You want a smaller header file?  I
don't see that as being an argument.  Heck, you can make a very small
libtcc.h file:

#ifndef LIBTCC_H
#define LIBTCC_H

/******************************************************************
*
* Please see tcc-doc.txt or tcc-doc.html for information on how to
* use the routines defined.  Or visit http://...
*
******************************************************************/

#ifndef LIBTCCAPI
# define LIBTCCAPI
#endif

#ifdef __cplusplus
extern "C" {
#endif

#define TCC_OUTPUT_MEMORY        0 
#define TCC_OUTPUT_EXE           1 
#define TCC_OUTPUT_DLL           2 
#define TCC_OUTPUT_OBJ           3 
#define TCC_OUTPUT_PREPROCESS    4 
#define TCC_OUTPUT_FORMAT_ELF    0 
#define TCC_OUTPUT_FORMAT_BINARY 1 
#define TCC_OUTPUT_FORMAT_COFF   2 
#define TCC_RELOCATE_AUTO (void*)1

struct TCCState;

typedef struct TCCState TCCState;

LIBTCCAPI TCCState *tcc_new(void);
LIBTCCAPI void tcc_delete(TCCState *s);
LIBTCCAPI void tcc_enable_debug(TCCState *s);
LIBTCCAPI void tcc_set_error_func(TCCState *s, void *error_opaque,void 
(*error_func)(void *opaque, const char *msg));
LIBTCCAPI int tcc_set_warning(TCCState *s, const char *warning_name, int value);
LIBTCCAPI const char * tcc_set_linker(TCCState *s, char *option, int multi);
LIBTCCAPI int tcc_add_include_path(TCCState *s, const char *pathname);
LIBTCCAPI int tcc_add_sysinclude_path(TCCState *s, const char *pathname);
LIBTCCAPI void tcc_define_symbol(TCCState *s, const char *sym, const char 
*value);
LIBTCCAPI void tcc_undefine_symbol(TCCState *s, const char *sym);
LIBTCCAPI int tcc_add_file(TCCState *s, const char *filename);
LIBTCCAPI int tcc_compile_string(TCCState *s, const char *buf);
LIBTCCAPI int tcc_set_output_type(TCCState *s, int output_type);
LIBTCCAPI int tcc_add_library_path(TCCState *s, const char *pathname);
LIBTCCAPI int tcc_add_library(TCCState *s, const char *libraryname);
LIBTCCAPI int tcc_add_symbol(TCCState *s, const char *name, const void *val);
LIBTCCAPI int tcc_output_file(TCCState *s, const char *filename);
LIBTCCAPI int tcc_run(TCCState *s, int argc, char **argv);
LIBTCCAPI int tcc_relocate(TCCState *s1, void *ptr);
LIBTCCAPI void *tcc_get_symbol(TCCState *s, const char *name);
LIBTCCAPI void tcc_set_lib_path(TCCState *s, const char *path);

#ifdef __cplusplus
}
#endif
#endif

  There you go---small libtcc.h.  

  Further more, zlib, a library that does way less than compile C code, has
a 1200 line header file.  jpeglib.h is 1100.  png.h is 3362.  Not wanting to
export a function because it makes the header file smaller is a piss-poor
reason to do it.

  -spc (libtcc.h clocks in at only 113 ... )

[1]     I haven't checked the code, so it may very well be that recvfrom()
        does not call recvmsg() but both call the same set of subroutines.

[2]     It runs over IP, but has its own protocol.

[3]     http://www.joelonsoftware.com/articles/LeakyAbstractions.html




reply via email to

[Prev in Thread] Current Thread [Next in Thread]