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
> 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
[...]
> 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 <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 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.
> 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