public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: binutils@sourceware.org
Subject: [PATCH v2 1/3] ctf: fix various dreadful typos in the ctf_archive format comments
Date: Tue, 10 Jan 2023 13:00:48 +0000	[thread overview]
Message-ID: <20230110130050.366404-2-nick.alcock@oracle.com> (raw)
In-Reply-To: <20230110130050.366404-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 4414cb0ebed..4263799f82d 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:[~2023-01-10 13:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-10 13:00 [PATCH v2 0/3] A few backlogged fixes, and a crash bug Nick Alcock
2023-01-10 13:00 ` Nick Alcock [this message]
2023-01-10 13:00 ` [PATCH v2 2/3] libctf: skip the testsuite from inside dejagnu Nick Alcock
2023-01-10 13:00 ` [PATCH v2 3/3] libctf: ctf-link outdated input check faulty Nick Alcock
2023-01-11 17:21   ` [PATCH 2.40 " Nick Alcock
2023-01-12 13:43     ` Nick Clifton
2023-01-12 14:46       ` Nick Alcock
2023-01-12 15:39         ` Nick Alcock
2023-01-13 11:14           ` Nick Clifton

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=20230110130050.366404-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).