Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Question about interpreter == NULL

6 views
Skip to first unread message

Juergen Boemmels

unread,
Jul 31, 2003, 10:54:41 AM7/31/03
to Perl6 Internals
Hello,

Some Parrot functions allow a NULL interpreter and some
don't. Parrot_warn for example fails badly if called with a
NULL-interpreter, but in config/gen/platform/ansi.c in
Parrot_floatval_time it is exactly called in this way.

So what functions should allow for a NULL interpreter, which should
assert (interpreter != NULL) and which should just asume a non-NULL
interpreter?

Parrot_sprintf?
PIO_eprintf?
Parrot_warn?

bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47

Leopold Toetsch

unread,
Jul 31, 2003, 3:03:21 PM7/31/03
to Juergen Boemmels, perl6-i...@perl.org
Juergen Boemmels <boem...@physik.uni-kl.de> wrote:
> Hello,

> Some Parrot functions allow a NULL interpreter and some
> don't. Parrot_warn for example fails badly if called with a
> NULL-interpreter, but in config/gen/platform/ansi.c in
> Parrot_floatval_time it is exactly called in this way.

> So what functions should allow for a NULL interpreter, which should
> assert (interpreter != NULL) and which should just asume a non-NULL
> interpreter?

> Parrot_sprintf?
> PIO_eprintf?
> Parrot_warn?

IMHO we just need 2 functions that check for a valid interpreter:

PIO_eprintf
PIO_printf

for printing to stderr/stdout during 1st interpreter construction &
destruction if something goes wrong. In all other cases we have an
valid interpreter (or an parent interpreter if any).

> bye
> boe

leo

Juergen Boemmels

unread,
Jul 31, 2003, 3:26:03 PM7/31/03
to l...@toetsch.at, perl6-i...@perl.org
Leopold Toetsch <l...@toetsch.at> writes:

[...]

> PIO_eprintf
> PIO_printf
>
> for printing to stderr/stdout during 1st interpreter construction &
> destruction if something goes wrong. In all other cases we have an
> valid interpreter (or an parent interpreter if any).

This means all the Parrot_warn(NULL,...) in config/gen/platform/ansi.c
are invalid. Ok remove them

Index: config/gen/platform/ansi.c
===================================================================
RCS file: /cvs/public/parrot/config/gen/platform/ansi.c,v
retrieving revision 1.7
diff -u -r1.7 ansi.c
--- config/gen/platform/ansi.c 14 Jul 2003 07:58:20 -0000 1.7
+++ config/gen/platform/ansi.c 31 Jul 2003 19:22:42 -0000
@@ -27,7 +27,6 @@
{
/* unable to provide this level of precision under ANSI-C, so just fall
back to intval time for this. */
- Parrot_warn(NULL, PARROT_WARNINGS_PLATFORM_FLAG, "Parrot_floatval_time not accurate");
return (FLOATVAL)Parrot_intval_time();
}

@@ -39,7 +38,6 @@
void
Parrot_sleep(unsigned int seconds)
{
- Parrot_warn(NULL, PARROT_WARNINGS_PLATFORM_FLAG, "Parrot_sleep not implemented");
return;
}

@@ -92,7 +90,6 @@
void *
Parrot_dlopen(const char *filename)
{
- Parrot_warn(NULL, PARROT_WARNINGS_PLATFORM_FLAG, "Parrot_dlopen not implemented");
return NULL;
}

@@ -115,7 +112,6 @@
void *
Parrot_dlsym(void *handle, const char *symbol)
{
- Parrot_warn(NULL, PARROT_WARNINGS_PLATFORM_FLAG, "Parrot_dlsym not implemented");
return NULL;
}

@@ -127,7 +123,6 @@
int
Parrot_dlclose(void *handle)
{
- Parrot_warn(NULL, PARROT_WARNINGS_PLATFORM_FLAG, "Parrot_dlclose not implemented");
return 0;
}

Leopold Toetsch

unread,
Jul 31, 2003, 4:41:22 PM7/31/03
to Juergen Boemmels, l...@toetsch.at, perl6-i...@perl.org
Juergen Boemmels wrote:

> Leopold Toetsch <l...@toetsch.at> writes:
>
> [...]
>
>
>>PIO_eprintf
>>PIO_printf
>>
>>for printing to stderr/stdout during 1st interpreter construction &
>>destruction if something goes wrong. In all other cases we have an
>>valid interpreter (or an parent interpreter if any).
>>
>
> This means all the Parrot_warn(NULL,...) in config/gen/platform/ansi.c
> are invalid. Ok remove them

Not exactly :-)
platform/ansi and probably miniparrot using such function should IMHO
and probably just PANIC() or throw an exception, which might then do panic.
Its very likely a sever error, when unsupported platform functions are
called during parrot bootstrap, which is that what I presume
miniparrot/ansi.c will finally be doing.

leo

Juergen Boemmels

unread,
Aug 1, 2003, 7:24:10 AM8/1/03
to Leopold Toetsch, l...@toetsch.at, perl6-i...@perl.org
Leopold Toetsch <l.to...@nextra.at> writes:

> Juergen Boemmels wrote:
>
> > Leopold Toetsch <l...@toetsch.at> writes:
> > [...]
>
> >
>
> >>PIO_eprintf
> >>PIO_printf
> >>
> >>for printing to stderr/stdout during 1st interpreter construction &
> >>destruction if something goes wrong. In all other cases we have an
> >>valid interpreter (or an parent interpreter if any).
> >>
> > This means all the Parrot_warn(NULL,...) in
> > config/gen/platform/ansi.c
>
> > are invalid. Ok remove them
>
> Not exactly :-)
> platform/ansi and probably miniparrot using such function should IMHO
> and probably just PANIC() or throw an exception, which might then do
> panic.

Most of them don't need to panic, they do the right thing:
Parrot_floatval_time: returns a float representing the time but only with
seconds resolution. But the resolution is always platform
dependend.
Parrot_sleep: No need to panic here. Maybe busy waiting. Yes this is ugly
but portable.
Parrot_dlopen: It cant open a dynamic library so it fails -> returns NULL.
The caller must already check this as there also might be a
"File not found"
Parrot_dlsym:
Parrot_close: These two should never be called as there never will be
a valid handle. These may PANIC() or just return error.

> Its very likely a sever error, when unsupported platform functions are
> called during parrot bootstrap, which is that what I presume
> miniparrot/ansi.c will finally be doing.

They should not fail more drastic than necessary. Only fail if its not
possible to report an error to the upper level.

Leopold Toetsch

unread,
Aug 1, 2003, 7:58:05 AM8/1/03
to Juergen Boemmels, perl6-i...@perl.org
Juergen Boemmels <boem...@physik.uni-kl.de> wrote:

> They should not fail more drastic than necessary. Only fail if its not
> possible to report an error to the upper level.

Yep. That's right. To panic() is not necessary nost of the time.

> bye
> boe

leo

0 new messages