poke-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Check return value of pk_str_concat


From: Tim Rühsen
Subject: Re: [PATCH] Check return value of pk_str_concat
Date: Wed, 6 May 2020 16:58:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 06.05.20 16:39, Jose E. Marchesi wrote:
> 
> 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.



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


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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