public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: binutils@sourceware.org
Subject: [PATCH 1/4] ctf: fix various dreadful typos in the ctf_archive format comments
Date: Fri, 16 Dec 2022 13:25:38 +0000	[thread overview]
Message-ID: <20221216132541.45791-2-nick.alcock@oracle.com> (raw)
In-Reply-To: <20221216132541.45791-1-nick.alcock@oracle.com>

When defining a format it helps to a) get the endianness right when you
explicitly state what it is and b) define things in terms of fields that
exist rather than fields that don't.

(A bunch of changes of names during implementation were not reflected in
these comments...)

Thanks to Jose "Eye of the Eagle" Marchesi for spotting these.

include/
	* ctf.h (struct ctf_archive) [ctfa_ctfs]: The size element of
	this is in little-endian byte order, not network byte order.
	(struct ctf_archive_modent): This is positioned right after the
	end fo the struct ctf_archive, not at the offset of a
	nonexistent field.  The number of elements in the array depends
	on ctfa_ndicts, not another nonexistent field.
---
 include/ctf.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/ctf.h b/include/ctf.h
index 698aab3eab6..6b17236254f 100644
--- a/include/ctf.h
+++ b/include/ctf.h
@@ -599,13 +599,13 @@ struct ctf_archive
   /* Offset of the name table.  */
   uint64_t ctfa_names;
 
-  /* Offset of the CTF table.  Each element starts with a size (a uint64_t
-     in network byte order) then a ctf_dict_t of that size.  */
+  /* Offset of the CTF table.  Each element starts with a size (a little-
+     endian uint64_t) then a ctf_dict_t of that size.  */
   uint64_t ctfa_ctfs;
 };
 
-/* An array of ctfa_nnamed of this structure lies at
-   ctf_archive[ctf_archive->ctfa_modents] and gives the ctfa_ctfs or
+/* An array of ctfa_ndicts of this structure lies at
+   ctf_archive[sizeof(struct ctf_archive)] and gives the ctfa_ctfs or
    ctfa_names-relative offsets of each name or ctf_dict_t.  */
 
 typedef struct ctf_archive_modent
-- 
2.39.0.267.g7648178303


  reply	other threads:[~2022-12-16 13:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-16 13:25 [PATCH 0/4] A few backlogged build-system problems Nick Alcock
2022-12-16 13:25 ` Nick Alcock [this message]
2022-12-16 13:25 ` [PATCH 2/4] libtool.m4: adjust kludge for ignoring syntax errors Nick Alcock
2022-12-16 13:54   ` Andreas Schwab
2022-12-16 15:11     ` Nick Alcock
2022-12-16 15:18       ` Andreas Schwab
2022-12-19 17:30         ` Nick Alcock
2022-12-16 13:25 ` [PATCH 3/4] Regenerate affected configures Nick Alcock
2022-12-16 13:25 ` [PATCH 4/4] libctf: skip the testsuite from inside dejagnu Nick Alcock
2022-12-20 12:53 ` [PATCH 0/4] A few backlogged build-system problems Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221216132541.45791-2-nick.alcock@oracle.com \
    --to=nick.alcock@oracle.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).