Date: Tue, 19 Feb 2002 18:38:55 -0600 From: Joe Halpin <joe.halpin@attbi.com> Cc: FreeBSD-Standards <freebsd-standards@FreeBSD.ORG> Subject: Re: pathchk - review Message-ID: <3C72F01F.510DCB4B@attbi.com> References: <20020129210829.GC50337@madman.nectar.cc> <20020205232519.N7805-101000@opus.sandiegoca.ncr.com> <20020212170303.B55750@espresso.q9media.com> <20020217020217.GB46829@madman.nectar.cc> <20020217004339.J57687@espresso.q9media.com> <20020219144756.A636@hda.hda.com> <20020219184515.G5526@espresso.q9media.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Barcroft wrote: > > Peter Dufault <dufault@hda.hda.com> writes: > > > The type is a pointer to a read-only string. The type he was really > > > looking for was a read-only pointer to a read-only string: > > > > > > const char * const VARIABLE; > > > > > > But as I suggested, manifest constants are better. > > > > No, debuggers don't handle them well. "When possible, avoid the > > preprocessor" IMHO. The same applies to magic numbers versus enums. > > Obviously what you're saying doesn't apply to the code in question. > We will never need to debug fprint(3) or err(3) calls. Also, as Bruce > pointed out in a private e-mail, atleast two of the variables should > be string literals, since they are only used once. > > I also disagree with what you're saying in the general case. Things > that are read-only aren't usually the things one is interesting in, > when debugging. I've attached a sample program which uses the two > forms discussed above. Are you able to differentiate them when you > debug this program? I'm certainly not able to. I missed the beginning of this, so I might be saying something irrelevant, but it seems to me that one very good reason for using const char pointers rather than the preprocessor is that const char * respects scope, and won't blindly overwrite other things.For the same reason, I prefer inline functions to function-like macros, not to mention the fact that inline functions offer some type safety. I became a believer in this after a bad experience with curses macros. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C72F01F.510DCB4B>