From: Tom de Vries <tdevries@suse.de>
To: Florian Weimer <fweimer@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>, mark@klomp.org, dwz@sourceware.org
Subject: [committed] Change files var in main to char **
Date: Fri, 19 Mar 2021 17:43:13 +0100 [thread overview]
Message-ID: <6743f221-68bc-9ce6-113a-bffa46d912b6@suse.de> (raw)
In-Reply-To: <87czvwpa4f.fsf@oldenburg.str.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]
[ was: Re: [committed] Make main more readable ]
On 3/18/21 7:52 PM, Florian Weimer wrote:
> * Tom de Vries:
>
>> I've prepared a patch implementing that suggestion. Does that address
>> your concerns?
>>
>> [ FWIW, I've read through a C99 draft pdf to refresh my memory on this
>> topic. Looking at the effective type of **argv, AFAIU it falls into the
>> catagory "For all other accesses to an object having no declared type,
>> the effective type of the object is simply the type of the lvalue used
>> for the access". In other words, the effective type is char.
>>
>> Then I read:
>> ...
>> An object shall have its stored value accessed only by an lvalue
>> expression that has one of the following types:
>> — a qualified version of a type compatible with the effective type of
>> the object,
>> ...
>>
>> So, const char is a qualified version of a type char compatible with the
>> effective type of the object (char).
>>
>> So I still don't see the problem. ]
>
> I think the issue is about the char * array elements, not the individual
> bytes in the strings themselves.
I see, that explains, I somehow managed to miss that.
I've updated the log message, and committed.
Thanks,
- Tom
[-- Attachment #2: 0001-Change-files-var-in-main-to-char.patch --]
[-- Type: text/x-patch, Size: 2021 bytes --]
Change files var in main to char **
The cast on &argv[optind] to const char **:
...
main (int argc, char *argv[])
{
...
const char **files;
...
files = (const char **)&argv[optind];
...
violates the aliasing rules.
The array element argv[i] aliases with the array element files[i],
but the types of the elements (char * vs. const char *) are not compatible types.
Since we access the elements using both types (const char * in dwz_files/dwz,
char * in getopt_long), there's a violation.
Fix this by changing the type of files to char **.
2021-03-18 Tom de Vries <tdevries@suse.de>
* dwz.c (dwz): Make files param a char **.
(dwz_files): Make files param char *[].
(main): Make files var a char **.
---
dwz.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/dwz.c b/dwz.c
index 7b67960..a7aa23b 100644
--- a/dwz.c
+++ b/dwz.c
@@ -15267,7 +15267,7 @@ struct file_result
over FILE. */
static int
dwz (const char *file, const char *outfile, struct file_result *res,
- struct file_result *resa, const char **files)
+ struct file_result *resa, char **files)
{
DSO *dso;
int ret = 0, fd;
@@ -16285,7 +16285,7 @@ dwz_one_file (const char *file, const char *outfile)
/* Dwarf-compress FILES. If HARDLINK, detect if some files are hardlinks and
if so, dwarf-compress just one, and relink the others. */
static int
-dwz_files (int nr_files, const char *files[], bool hardlink)
+dwz_files (int nr_files, char *files[], bool hardlink)
{
int ret = 0;
int i;
@@ -16413,7 +16413,7 @@ main (int argc, char *argv[])
const char *outfile;
bool hardlink;
int nr_files;
- const char **files;
+ char **files;
if (elf_version (EV_CURRENT) == EV_NONE)
error (1, 0, "library out of date");
@@ -16422,7 +16422,7 @@ main (int argc, char *argv[])
hardlink = false;
parse_args (argc, argv, &hardlink, &outfile);
nr_files = argc - optind;
- files = (const char **)&argv[optind];
+ files = &argv[optind];
if (nr_files <= 1)
{
prev parent reply other threads:[~2021-03-19 16:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 13:14 [committed] Make main more readable Tom de Vries
2021-03-17 13:18 ` Jakub Jelinek
2021-03-17 13:37 ` Tom de Vries
2021-03-17 17:28 ` Jakub Jelinek
2021-03-18 10:30 ` Tom de Vries
2021-03-18 18:52 ` Florian Weimer
2021-03-19 16:43 ` Tom de Vries [this message]
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=6743f221-68bc-9ce6-113a-bffa46d912b6@suse.de \
--to=tdevries@suse.de \
--cc=dwz@sourceware.org \
--cc=fweimer@redhat.com \
--cc=jakub@redhat.com \
--cc=mark@klomp.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).