poke-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] pkl_resolve_module: On failure give a more useful diagnostic


From: Jose E. Marchesi
Subject: Re: [PATCH] pkl_resolve_module: On failure give a more useful diagnostic
Date: Sat, 23 May 2020 11:55:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

    Okay, but I suggest that we also change pk_fatal to call abort instead
    of exit.   That way, if anything fatal happens you have a core file
    with whicht the root of the problem can be found.
    
Yes I totally agree :)
Thanks!
    
    
    On Sat, May 23, 2020 at 10:54:50AM +0200, Jose E. Marchesi wrote:
         
         Hi John.
         
             ---
              libpoke/pkl.c | 6 +++++-
              1 file changed, 5 insertions(+), 1 deletion(-)
             
             diff --git a/libpoke/pkl.c b/libpoke/pkl.c
             index 0ba3946e..91b1f56c 100644
             --- a/libpoke/pkl.c
             +++ b/libpoke/pkl.c
             @@ -673,7 +673,11 @@ pkl_resolve_module (pkl_compiler compiler,
                                        PKL_ENV_NS_MAIN,
                                        "load_path",
                                        &back, &over);
             -    assert (tmp != NULL);
             +    if (tmp == NULL)
             +      {
             +  fprintf (stderr, "Cannot resolve module %s\n", module);
             +  abort ();
             +      }
              
                  val = pvm_env_lookup (runtime_env, back, over);
                  assert (val != PVM_NULL);
         
         I would rather not have the library printing diagnostics in
         stdout/stderr.  Looking at the prototype of pkl_resolve_module:
         
         /* Look for the module described by MODULE in the load_path of the
            given COMPILER, and return the path to its containing file.
         
            If the module is not found, return NULL.
         
            If FILENAME_P is not zero MODULE is interpreted as a relative file
            path instead of a module name.  */
         
         char *pkl_resolve_module (pkl_compiler compiler, const char *module,
                                   int filename_p)
           __attribute__ ((visibility ("hidden")));
         
         Maybe in this case we should just return NULL if load_path is not
         defined.  The caller of pkl_resolve_module, in pkl-tab.y, checks for
         this and does the right thing.
         
         WDYT?



reply via email to

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