poke-devel
[Top][All Lists]
Advanced

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

some code constructs in Poke


From: Indu Bhagat
Subject: some code constructs in Poke
Date: Thu, 25 Feb 2021 16:31:46 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1

Hello,

While working on making some improvements to the CTF pickles in GNU Poke, I ran into some aspects that I wanted to discuss.

1. Forward declaration of functions in Poke.

It does not look like Poke allows forward declaration of functions. Without forward declarations allowed, some code patterns are simply not permitted.

    func B ()
    {
      if (condB)
        A ();
    }

    func A ()
    {
      if (condA)
        B ();
    }

Above cannot be achieved. Is my understanding correct ?

2. Good to have (perhaps?): Some mechanism for structs to convey information to each other.

In pickles/ctf.pk, see how type CTF_Func_Args needs to be defined inside CTF_Type due to its dependence on info.vlen. Well, this works fine as far as the requirement of "specification of types" goes.

   type CTF_Type =
     struct
       {
         CTF_Info info;
         ...

         type CTF_Func_Args =
           struct
             {
               CTF_Type_Id[info.vlen] arg_types;
               uint32[info.vlen % 2] padding;
             };

          /* Data, that depends on the kind of the type.  */
          union
          {
            ...
            CTF_Func_Args func_args : info.kind == CTF_KIND_FUNCTION;
            ...
          } data;
        };


The side effect of this, however, is that CTF_Func_Args is not a type at file-scope, so this limits the developers from writing functions for the type at hand. E.g., see the need to write a function that takes CTF_Func_Args as an argument-

  fun ctf_dump_func_args = (CTF_Func_Args fargs) void: {}

Instead one can workaround by writing

   fuc ctf_dump_func_args = (CTF_Type t) void: {}

and do the necessary exception handling etc.

I am a bit split on this one. The current behavior is logical, no denial; but defining functions for the parent type looks a bit twisted. The positive about the current way of working is that the syntax around type definitions is more C-like...WDYT ?

Thanks
Indu



reply via email to

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