Implement clear function

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Look at the files outputted by protoc-c

What is the expected output? What do you see instead?
There is no clear method for the generated structures.

What version of the product are you using? On what operating system?
protobuf-c 0.15, protobuf 2.4.1, Windows 7 and embedded ARM Cortex-M3

Please provide any additional information below.
Currently, without a clear function, it's pretty hard to reuse an existing 
structure, requiring the user to write his own clear implementation. This is 
useful for resource-constrained environments such as microcontrollers, where 
there is no malloc() and structures must be created statically and reused.

Original issue reported on code.google.com by ronanpaixao@gmail.com on 19 Nov 2011 at 7:17

[GoogleCodeExporter]

The protobuf-c library currently makes no specifications about how your 
messages are allocated.  (That's why there is "free_unpacked" method not "free" 
- in general, we can only tell you how to deallocate if you tell us how to 
allocate.)

Of course, we have an "init" function if you don't care about deallocating.

There are at least two workarounds... (i don't see an attachment so i can't 
comment on your exact change)

(1) use a static buffer, but copy it before sending it.

    static MyMessage message_default_value = MY__MESSAGE__INIT;
    static void send_message(...)
    {
      MyMessage to_send = message_default_value;   // or just use MY__MESSAGE_INIT
      to_send.... = ...;   /// set up your values
      my__message__pack (&to_send, ...);
    }

or you can use
    static MyMessage my_message;
    void send_message(...)
    { my__message__init (&my_message);
      ...
    }

in both cases, YOU are responsible for memory management - if you allocate, you 
must free.

Original comment by lahike...@gmail.com on 29 Nov 2011 at 2:57

• Changed state: WontFix

[GoogleCodeExporter]

It is indeed good to let the user allocate and deallocate memory, specially in 
a bare-metal system where a non-standard OS may be used. I myself use static 
allocation mostly. However, there could be helper functions (maybe with weak 
linking?) because it's pretty annoying to write allocation and deallocation 
functions for every repeated member. That way, the user would only have to 
write the function once.

Original comment by ronanpaixao@gmail.com on 29 Nov 2011 at 10:47

[GoogleCodeExporter]

i do have some plans along these lines: namely allowing the messages to specify 
their own allocation policy.

then you'll be able to write a helper library for supporting read/write access.

i can't imagine outputting a function for each repeated member, but who knows, 
i guess.

Original comment by lahike...@gmail.com on 14 Dec 2011 at 4:11