pcp
[Top] [All Lists]

Re: [pcp] PCP Updates: Fix Bug #1035: PMCD Should Not Fail to Start if N

To: Dave Brolley <brolley@xxxxxxxxxx>
Subject: Re: [pcp] PCP Updates: Fix Bug #1035: PMCD Should Not Fail to Start if NSS Fails to Initialize
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Wed, 26 Mar 2014 15:00:26 -0400 (EDT)
Cc: PCP Mailing List <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5332F0EA.4010803@xxxxxxxxxx>
References: <53319A17.6060608@xxxxxxxxxx> <y0m7g7i8bx2.fsf@xxxxxxxx> <5332F0EA.4010803@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: KZjf9nUgO6QCdjrzdsq8cwqU9YsAgw==
Thread-topic: PCP Updates: Fix Bug #1035: PMCD Should Not Fail to Start if NSS Fails to Initialize
Hi Dave,

----- Original Message -----
> [...]
> Frank and I talked a bit more about this and he correctly noted that,
> with this change, __pmSecureServerSetup() no longer contains a code path
> which returns anything other than 0. He has suggested changing it to
> return 'void'. I believe that it is possible that someday, such an error
> path could once again exist (e.g. if we were to implement Frank's
> example of having a pmcd/pmproxy mode for which secure connections are
> required). In that case we would be removing the return code only to add
> it again later. Even though this is currently only used by pmcd and
> pmproxy, I think we should think twice about changing the API if we
> think it could change back in the future.
> 
> Thoughts?

I tend to agree with you Dave - lets leave it as is please.  There's no
harm in always returning zero at this stage, and the option remains there
when we need it down the track (needed it in the past, will probably need
it again someday - it could easily have to malloc something at some point
then we'd need to handle the error return again I guess).

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>