Subject: Re: __UNCONST(a)
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 07/05/2004 19:50:41
[ On Sunday, July 4, 2004 at 16:38:46 (+0100), David Laight wrote: ]
> Subject: Re: __UNCONST(a)
>
> This is one reason why I dislike using casts to remove compiler/lint
> warnings - it can hide a real error.
Indeed.
Personally I'd rather see the compiler emit the warning when compiling
the likes of strstr() and to find a big fat human-readable comment with
strstr.c that explains why the compiler will emit a warning when
compiling that code.
I recently had the "pleasure" of porting some code to a recent version
of the MIPS-Pro compiler (on SGI IRIX 6.x). They've got some fairly
powerful facilities for controlling warning levels using lint-style
comments, and warnings that the kind that "-Werror" would turn into
non-zero exit codes can be reduced to what they call "remarks" which are
still emitted by the compiler but which do not cause a non-zero exit
code. However I think doing that kind of thing in GCC would require a
heck of a lot more organization and control than seems to be possible in
most open source projects in order to assign identifiers or index
numbers for each and every type of error, and so on, and to make sure
they stay consistent across platforms and across releases.
It's also why given what I know now I would redesign the strstr() API,
for example, thusly:
int
strstr(const char *big, const char *little, const char **result);
so that it would be the caller's responsibility to either pass the
address of a "const char *" variable through "result" or else apply a
cast to add the "const" qualifier at that point; instead of forcing the
implementation to create a possible problem where "const" is invisibly
lost through pointer aliasing within the system library.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>