git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 3/3] Documentation: document difference between release and free

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 24, 2024, 16:52 UTC
Message-ID
<xmqqed7iwx4r.fsf@gitster.g>
In-Reply-To
<5e1de3c3159968e897a83c05dae5e8504d37a16c.1721818488.git.ps@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
Show 12 quoted lines
> We semi-regularly have discussions around whether a function shall be
> named `release()` or `free()`. For most of the part we use these two
> terminologies quite consistently though:
>
>   - `release()` only frees internal state of a structure, whereas the
>     structure itself is not free'd.
>
>   - `free()` frees both internal state and the structure itself.
>
> Carve out a space where we can add idiomatic names for common functions
> in our coding guidelines. This space can get extended in the future when
> we feel the need to document more idiomatic names.

We have _clear() in some subsystem/API. Are we sure the listed two are sufficient and _clear() can be replaced with one of them (perhaps _release())?

Show 28 quoted lines
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  Documentation/CodingGuidelines | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 34fcbcb5a4..ace4c4ad0c 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -560,6 +560,18 @@ For C programs:
>  
>  	void reset_strbuf(struct strbuf *buf);
>  
> + - There are several common idiomatic names for functions performing
> +   specific tasks on structures:
> +
> +    - `<struct>_init()` initializes a structure without allocating the
> +      structure itself.
> +
> +    - `<struct>_release()` releases a structure's contents without
> +      freeing the structure.
> +
> +    - `<struct>_free()` releases a structure's contents and frees the
> +      structure.
> +
>  For Perl programs:
>  
>   - Most of the C guidelines above apply.
Previous: Patrick SteinhardtNext: Patrick Steinhardt
Message 18 of 29 in “Documentation: some coding guideline updates”
  1. 0/3 Documentation: some coding guideline updatesPatrick Steinhardt, Jul 24, 2024
  2. 1/3 Documentation: clarify indentation style for C preprocessor directivesPatrick Steinhardt, Jul 24, 2024
  3. Junio C HamanoJul 24, 2024
  4. Junio C HamanoJul 25, 2024
  5. Patrick SteinhardtJul 30, 2024
  6. 2/3 Documentation: document naming schema for struct-related functionsPatrick Steinhardt, Jul 24, 2024
  7. Karthik NayakJul 24, 2024
  8. Patrick SteinhardtJul 24, 2024
  9. Junio C HamanoJul 24, 2024
  10. Junio C HamanoJul 24, 2024
  11. Patrick SteinhardtJul 30, 2024
  12. 3/3 Documentation: document difference between release and freePatrick Steinhardt, Jul 24, 2024
  13. Karthik NayakJul 24, 2024
  14. Patrick SteinhardtJul 24, 2024
  15. Phillip WoodJul 24, 2024
  16. Junio C HamanoJul 24, 2024
  17. Patrick SteinhardtJul 30, 2024
  18. Junio C HamanoJul 24, 2024
  19. Patrick SteinhardtJul 30, 2024
  20. Karthik NayakJul 24, 2024
  21. 0/5 Documentation: some coding guideline updatesPatrick Steinhardt, Jul 30, 2024
  22. 1/5 clang-format: fix indentation width for preprocessor directivesPatrick Steinhardt, Jul 30, 2024
  23. Karthik NayakJul 30, 2024
  24. 2/5 Documentation: clarify indentation style for C preprocessor directivesPatrick Steinhardt, Jul 30, 2024
  25. 3/5 Documentation: document naming schema for structs and their functionsPatrick Steinhardt, Jul 30, 2024
  26. 4/5 Documentation: document idiomatic function namesPatrick Steinhardt, Jul 30, 2024
  27. 5/5 Documentation: consistently use spaces inside initializersPatrick Steinhardt, Jul 30, 2024
  28. Junio C HamanoJul 30, 2024
  29. Karthik NayakJul 31, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.