Glenn Burkhardt writes (to me directly as his outgoing server is ORBS'd):
> > Works fine on AIX 4.1.5.0.01. I cleaned up four compiler warnings produced
> > by gcc -Wall. One of them required adding an #include of <stdlib.h>, and
> > this required me to change getpass() to take a const char* rather than a
> > char*, to match the system prototype. Is this how getpass() is declared
> > everywhere?
>
> Linux: char *getpass( const char * prompt );
> SunOS: char *getpass( char *prompt );
> Solaris: char *getpass( const char *prompt );
Shantonu Sen <[EMAIL PROTECTED]> writes:
> >Works fine on AIX 4.1.5.0.01. I cleaned up four compiler warnings produced
> >by gcc -Wall. One of them required adding an #include of <stdlib.h>, and
> >this required me to change getpass() to take a const char* rather than a
> >char*, to match the system prototype. Is this how getpass() is declared
> >everywhere? If not, we'll need to add autoconf support to check the
> >declaration or (preferably) change this function name to be nmh_getpass().
>
> I think we should change the name. Our function's whole point is to
> obviate the need for any system-specific getpass(), so we shouldn't
> have to adhere to their prototypes unless we really want to.
Okay, I've changed it to nmh_getpass(). The only drawback of not calling it
getpass() is that in the future people may accidentally use plain getpass()
instead of nmh_getpass() and unless they're on an OS where getpass() fails
to prompt, they won't know that they shouldn't have done that.
I've added a "nmh-local functions to use in preference to OS versions"
section to README.developers documenting this -- anyone know of any other
functions in this boat besides [nmh_]getpass()?
> The only reason why I didn't stick with const char* was that I didn't see
> the relevance of being so specific. It's not that important.
Well, if you have a const char*, you won't be able to pass it to a function
that takes a plain char*. In general, functions that don't change what's
pointed to by their pointer paramters should declare them const. It can
also be an optimization issue -- the compiler can do more optimization if it
knows that a pointed-to value shouldn't change across a function call.
> >I notice the memory allocated by calloc() is leaked. Not that big a deal
> >for nmh's short-running programs, I guess, but it might at least be worth a
> >comment acknowledging the leak and giving the justification.
>
> I only added the explicity calloc because my compiler (granted,
> without -Wall), was complaining about getpass returning a local
> variable. instead of declaring buf[SIZE], if I manually calloc'ed it,
> the warning went away. I'll fix this up in the next few days.
Um, yeah, that warning was pointing out a real bug (as was the one that said
the != EOF comparison would always return true). The solution isn't to
calloc() it, though -- buf just needs to be declared static. That's what
the system getpass() does. I've fixed this.
It's happened multiple times in the past that people have introduced
warnings that I later ended up cleaning up because they didn't use
--enable-debug when they configured nmh, and thus weren't using -Wall. I've
changed configure.in so -Wall is now included during optimized compiles as
well.
> >The copyright notice sort of implies that we're using the unchanged
> >version. We should probably add "Portions of this code are" to the
> >beginning, eh?
>
> Sounds good.
Done.
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
[EMAIL PROTECTED] | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
