Code Question in FAT Filesystem
Arnout Vandecappelle
arnout at mind.be
Tue Aug 24 09:12:41 UTC 2010
I agree that const char * const is most likely the intended declaration.
By the way, in C90 repeating the const is illegal as well. I don't know why they suddenly allowed it in C99 (but not C++)...
Regards,
Arnout
On Monday 23 August 2010 21:35:01, Somervill, Kevin M. (LARC-D203) wrote:
> I think the issue is the "const char const" that Joel originally posted. The declaration "const char * const foo" is not the same as "const char const * foo". In the latter, I believe both const qualifiers are associated with the char. It looks like this format is left over from K&R C, but "const char *" and "char const *" seem to be equivalent. Also, gcc will allow you to use as many const qualifiers as you like (eg. "const const const char stupid;" will compile using gcc but not g++).
>
> From the original email, you probably should swap the second const and the * to read "const char * const" so that neither the variable (MSDOS_DOT_NAME) nor the location (*MSDOS_DOT_NAME) can be changed. Perhaps like:
>
> msdos.h:extern const char * const MSDOS_DOT_NAME; /* ".", padded to MSDOS_NAME chars */
>
> IMO.
>
> ./ks
>
> | -----Original Message-----
> | From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] On
> | Behalf Of Eric Norum
> | Sent: Monday, August 23, 2010 2:30 PM
> | To: Joel Sherrill
> | Cc: rtems-users at rtems.org
> | Subject: Re: Code Question in FAT Filesystem
> |
> | I'm no expert on C++, but for C at least, I don't see any type qualifier being
> | specified more than once:
> | const char *const foo
> | declares foo to be a constant pointer to constant character(s)
> |
> | This is different than
> | const *bar
> | which declares bar as a mutable pointer to constant character(s)
> |
> | or
> | char *const bletch
> | which declares bletch as a constant pointer to mutable character(s)
> |
> | So, with these declarations:
> | 1) bletch could never appear as an lvalue, but *bletch could
> | 2) *bar could never appear as an lvalue, but bar could
> | 2) foo could never appear as an lvalue nor could *foo appear as an
> | lvalue
> |
> | FWIW.
> |
> | On Aug 23, 2010, at 11:20 AM, Joel Sherrill wrote:
> |
> | > Hi,
> | >
> | > I came across this while trying to review
> | > Coverity output.
> | >
> | > [joel at iceland dosfs]$ grep "const char const" *
> | > msdos.h:extern const char const* MSDOS_DOT_NAME; /* ".", padded to
> | MSDOS_NAME chars */
> | > msdos.h:extern const char const* MSDOS_DOTDOT_NAME; /* ".", padded to
> | MSDOS_NAME chars */
> | > msdos_misc.c:const char const* MSDOS_DOT_NAME = ". ";
> | > msdos_misc.c:const char const* MSDOS_DOTDOT_NAME = ".. ";
> | >
> | > My understanding is that this is legal in C99 and
> | > illegal in C++.
> | >
> | > Coverity complains it is ...
> | >
> | > *dupl_type_qualifier*: type qualifier specified more than once
> | >
> | >
> | > Would it be OK to change these to "const char *MSDOS_DOT_"?
> | >
> | > --
> | > Joel Sherrill, Ph.D. Director of Research& Development
> | > joel.sherrill at OARcorp.com On-Line Applications Research
> | > Ask me about RTEMS: a free RTOS Huntsville AL 35805
> | > Support Available (256) 722-9985
> | >
> | >
> | > _______________________________________________
> | > rtems-users mailing list
> | > rtems-users at rtems.org
> | > http://www.rtems.org/mailman/listinfo/rtems-users
> |
> | --
> | Eric Norum
> | wenorum at lbl.gov
> |
> |
> | _______________________________________________
> | rtems-users mailing list
> | rtems-users at rtems.org
> | http://www.rtems.org/mailman/listinfo/rtems-users
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100824/90c78856/attachment-0001.html>
More information about the users
mailing list