docs/devel: Fix formatting of `Error **`

[PATCH] docs/devel: Fix formatting of `Error **`

Posted by J. Neuschäfer 2 weeks, 3 days ago

Since the ReST conversion, Error ** is expressed as Error ``*````*``, which is
rendered in HTML as Error *````*. Fix it so the HTML output resembles the
intended C syntax.

Fixes: 336a7451e8 ("docs: convert README, CODING_STYLE and HACKING to RST syntax")
Signed-off-by: J. Neuschäfer <j.neuschaefer@9elements.com>
---
 docs/devel/style.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/devel/style.rst b/docs/devel/style.rst
index 12e509d10de0b8c044c8429aaaee8855bde1deb5..b8edcf9316f059fe15415543098118b28fcaf99c 100644
--- a/docs/devel/style.rst
+++ b/docs/devel/style.rst
@@ -784,10 +784,10 @@ error, non-negative / -errno, non-null / null, or Error objects.
 Example: when a function returns a non-null pointer on success, and it
 can fail only in one way (as far as the caller is concerned), returning
 null on failure is just fine, and certainly simpler and a lot easier on
-the eyes than propagating an Error object through an Error ``*````*`` parameter.
+the eyes than propagating an Error object through an ``Error **`` parameter.
 
 Example: when a function's callers need to report details on failure
-only the function really knows, use Error ``*````*``, and set suitable errors.
+only the function really knows, use ``Error **``, and set suitable errors.
 
 Do not report an error to the user when you're also returning an error
 for somebody else to handle.  Leave the reporting to the place that

---
base-commit: 45cad8beca3ad75ebe63a36fdc60c98395fd2df1
change-id: 20260513-error-674f87f0d381

Best regards,
-- 
J. Neuschäfer <j.neuschaefer@9elements.com>

Re: [PATCH] docs/devel: Fix formatting of `Error **`

Posted by Pierrick Bouvier 2 weeks, 2 days ago

Hi J.

On 5/13/2026 8:06 AM, J. Neuschäfer wrote:
> Since the ReST conversion, Error ** is expressed as Error ``*````*``, which is
> rendered in HTML as Error *````*. Fix it so the HTML output resembles the
> intended C syntax.
> 
> Fixes: 336a7451e8 ("docs: convert README, CODING_STYLE and HACKING to RST syntax")
> Signed-off-by: J. Neuschäfer <j.neuschaefer@9elements.com>
> ---
>  docs/devel/style.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/devel/style.rst b/docs/devel/style.rst
> index 12e509d10de0b8c044c8429aaaee8855bde1deb5..b8edcf9316f059fe15415543098118b28fcaf99c 100644
> --- a/docs/devel/style.rst
> +++ b/docs/devel/style.rst
> @@ -784,10 +784,10 @@ error, non-negative / -errno, non-null / null, or Error objects.
>  Example: when a function returns a non-null pointer on success, and it
>  can fail only in one way (as far as the caller is concerned), returning
>  null on failure is just fine, and certainly simpler and a lot easier on
> -the eyes than propagating an Error object through an Error ``*````*`` parameter.
> +the eyes than propagating an Error object through an ``Error **`` parameter.
>  
>  Example: when a function's callers need to report details on failure
> -only the function really knows, use Error ``*````*``, and set suitable errors.
> +only the function really knows, use ``Error **``, and set suitable errors.
>  
>  Do not report an error to the user when you're also returning an error
>  for somebody else to handle.  Leave the reporting to the place that
> 
> ---
> base-commit: 45cad8beca3ad75ebe63a36fdc60c98395fd2df1
> change-id: 20260513-error-674f87f0d381
> 
> Best regards,

thanks for the fix, I'll pull this directly.

Tested-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>

Regards,
Pierrick