> Headerfiles may be protected with
>
>#ifdef __cplusplus
>extern "C" {
>#endif
Good idea, indeed. It will help us to solve the C/C++ naming convention
issue and thus to avoid the "_name@@decoration" unresolved external error.
I wonder at whether we should do
$su Dan
#
and protect the headers in
Hi,
the make shipped with Borland C++ builder doesn't like the makefiles
in the current way. I had to tweak the buildfiles a little in order to
get it Configure and compile. (It still does not link but thats
another story). I removed the appearences of && in the Makefiles with
${make_and} which is
On Saturday, August 30, 2003, at 07:59 , Nicholas Clark wrote:
You can't trust you data deserialiser. It can do evil on you before it
returns.
It's not the deserializer that you can't trust—it's the data. Of course
it's a security nightmare to deserialize data from an untrusted source.
That doe
On Fri, Aug 29, 2003 at 05:30:37PM +0200, Leopold Toetsch wrote:
> I think, we need a general solution for freeze, dump and clone. As shown
I don't know if this is relevant here, but I'll mention it in case.
For perl5 there isn't a single good generic clone system. Probably the
best (in terms of q
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Actually, I think the following interface would be better:
>void freeze(PMC *freezer);
>void thaw (PMC *thawer);
I'm thinking of (in horrible pseudo code ;-):
typedef struct {
size_t action_func_nr; // clone, freeze, thaw, dump
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> -#define PMC_sub(pmc) ((parrot_sub_t)((pmc)->cache.pmc_val))
> +#define PMC_sub(pmc) (*((parrot_sub_t *)&((pmc)->cache.pmc_val)))
This seems to work. Thanks for the patch.
(the tcc tinderbox seems to be missing a make realclean/Configure or
such though)
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Should we link imcc into libparrot?
That's definitely the plan, yes.
> Luke
leo
As discussed in the thread WRT "exit opcode" I have changed parrot's
ARGV handling, its passed in B now.
I have updated a bunch of examples and languages but I may have missed
some. "make test" succeeds (where there is one) in all but jako, which
didn't follow the change of .imc parsing yet.
p
Should we link imcc into libparrot? My reasoning is that then all these
compilers which call out to parrot externally can 1) avoid a temporary
file and 2) register their compilers with parrot, so generated code can
call back into the compiler. Also, I'll bet many times parrot embedders
will be us
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> yOn Fri, 29 Aug 2003, Leopold Toetsch wrote:
>> I have checked in a small change:
>> - B(in INT) throws an exception with severity C and
>> the given exit status.
> I think we might want to go a little further than this, but it's fine for
> now. We can ex
Dan Sugalski wrote:
>
> On Fri, 29 Aug 2003, Leopold Toetsch wrote:
>
>> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>> I think we'd be better served getting the freeze/thaw stuff in and
>>
>> We were just discussing this in the f'up.
>
> I read those, but I wanted to make sure the discussion went
11 matches
Mail list logo
