Re: [PATCH] Check return value of pk_str_concat

[Jose E. Marchesi]

    > Hi Tim.
    > 
    >     diff --git a/libpoke/pkl-fold.c b/libpoke/pkl-fold.c
    >     index 64feffdb..44bc2898 100644
    >     --- a/libpoke/pkl-fold.c
    >     +++ b/libpoke/pkl-fold.c
    >     @@ -586,6 +586,8 @@ EMUL_UU (bnoto) { return ~op; }
    >                                                                           
   \
    >                res = pk_str_concat (PKL_AST_STRING_POINTER (op1),         
   \
    >                                     PKL_AST_STRING_POINTER (op2), NULL);  
   \
    >     +          if (!res)                                                  
   \
    >     +            PKL_PASS_DONE;                                           
   \
    > 
    > 
    > That's not the right thing to do: PKL_PASS_DONE will basically continue
    > the compilation process.
    > 
    > IMO when compiler code finds an out-of-memory condition, it should raise
    > an ICE, i.e. to call pkl_ice.
    > 
    > Right now pkl_ice aborts the process, but we can change it in the future
    > to longjump to the out_of_memory label you are introducing:
    
    Then I change it to PKL_PASS_ICE.
    
Thanks.    
    
    > 
    >                new = pkl_ast_make_string (PKL_PASS_AST, res);             
   \
    >                free (res);                                                
   \
    >     diff --git a/libpoke/pkl.c b/libpoke/pkl.c
    >     index 3b6ae369..aeb6ecc9 100644
    >     --- a/libpoke/pkl.c
    >     +++ b/libpoke/pkl.c
    >     @@ -79,6 +79,16 @@ pkl_new (pvm vm, const char *rt_path)
    >           error and should be reported as such.  */
    >        {
    >          char *poke_rt_pk = pk_str_concat (rt_path, "/pkl-rt.pk", NULL);
    >     +    if (!poke_rt_pk)
    >     +      {
    >     +out_of_memory:
    >     +        pk_term_class ("error");
    >     +        pk_puts ("error: ");
    >     +        pk_term_end_class ("error");
    >     +        pk_puts ("out of memory\n");
    >     +
    >     +        return NULL;
    >     +      }
    > 
    > ... I wonder if libtextstyle allocates memory while stylizing? :)
    
    TL;DR: so what !
    
    Long version:
    What can we do ? If or if not, the internals can change at will.
    Also, rt_path could be megabytes long, but libtextstyle possible just
    takes a few bytes.
    
    And the, even puts / printf might allocate/reallocate memory internally.
    Even the kernel could be out-of-memory so that a write(1, ...) fails.

Heh ok, I'm convinced :)