From: Grant Erickson <erick205@umn.edu>
To: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH 1/6] [MTD-UTILS] nandwrite: Qualifier Clean-up
Date: Sun, 14 Sep 2008 12:43:37 -0700 [thread overview]
Message-ID: <C4F2B779.11AAC%erick205@umn.edu> (raw)
In-Reply-To: <lyzlmh8cn1.fsf@ensc-virt.intern.sigma-chemnitz.de>
On 9/9/08 10:14 AM, Enrico Scholz wrote:
> Grant Erickson <gerickson@nuovations.com> writes:
> >>> +static const char *mtd_device, *img;
>>>
>>> would it be possible to split this into two declarations? I
>>> really don't know if 'img' points to a constant or non-constant
>>> char...
>>
>> As currently implemented, both mtd_device and img point to
>> effectively read-only information. That is, there is no need to
>> modify or to attempt to modify what they point to.
>
> Sorry, I might be unclear here. My comment was about readability
> not about correctness; e.g. without studying C standard, it is
> not obvious to me, whether
>
> [ Examples Omitted ]
>
>
> When you think that answer to this question is trivial, then
> please explain 'char * const *a, *b;' ;)
Fair enough. Patch submitted.
>>>> -int main(int argc, char **argv)
>>>> +int main(int argc, char * const argv[])
>>>
>>> Is this really correct? C standard mentions only
>>>
>>> int main(void) { /* ... */ }
>>> int main(int argc, char *argv[]) { /* ... */ }
>>>
>>> as program entry points. I suggest to cast 'argv' to a corresponding
>>> data type when it is used.
>
>> adding the const qualifier simply conveys current program
>> intent. That is, the strings pointed to by argv are not
>> modified.
>
> Then, you can write
>
> | int main(int argc, char const * const argv[])
That's certainly possible as well; however, that was not the intent and, as
you cite with getopt below, would not accurately reflect how the program
respect argv.
> fwiw, the const'ness if argv[] content is violated when calling
> GNU getopt(3) as it reorders arguments. E.g.
>
> | argv[] = { "foo", "-a", "bar", "-c", NULL }
>
> is changed by this function to
>
> | argv[] = { "foo", "-a", "-c", "bar", NULL }
Understood on the operation of getopt. The declared intent was not that
order of the cells is constant but that the contents of the cells (i.e. the
strings) are.
Regards,
Grant
prev parent reply other threads:[~2008-09-14 19:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-08 4:24 [PATCH 1/6] [MTD-UTILS] nandwrite: Qualifier Clean-up Grant Erickson
2008-09-08 5:28 ` Artem Bityutskiy
2008-09-08 14:17 ` Josh Boyer
2008-09-09 4:51 ` Artem Bityutskiy
2008-09-09 13:23 ` Enrico Scholz
2008-09-09 16:30 ` Grant Erickson
2008-09-09 17:14 ` Enrico Scholz
2008-09-14 19:43 ` Grant Erickson [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=C4F2B779.11AAC%erick205@umn.edu \
--to=erick205@umn.edu \
--cc=enrico.scholz@sigma-chemnitz.de \
--cc=linux-mtd@lists.infradead.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