Subject: RE: [sv-cc] Final proposal for user data management
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Mar 27 2003 - 11:42:22 PST
Andrzej,
Please see comments below...
> -----Original Message-----
> From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> Sent: Thursday, March 27, 2003 11:21 AM
> To: Michael.Rohleder@motorola.com
> Cc: sv-cc@server.eda.org
> Subject: Re: [sv-cc] Final proposal for user data management
>
>
> > > void svPutUserData(svScope scope, void* userKey,
> void* userData);
> >
> > MICHAEL:
> > I would suggest to have a return value of type 'int' that
> reflects possible
> > error conditions like
> > - O.K.
> > - invalid scope
> > - invalid user key (do we permit NULL as userKey ?)
> > - collision in scope
> >
> > I really don't like functions that forget to tell me that
> something went wrong ...
>
> Run-time error?
> Sure, a status explicitly returned gives more flexibility,
> but in the case of
> non-void function it would take an additional output arg (&status).
DOUG: Since this is currently a void function, I roughly
followed Michael's suggestion. Collision in scope is not
a possible error, so I didn't include that one.
A similar problem exists for svGetUserData().
It returns a pointer type, void*.
What to do about error?
NULL return could be valid. (If user call svPutUserData() with NULL data).
NULL return could mean that svPutUserData() has never been called
previously.
NULL return could mean invalid scope, etc.
I tried my best in my LRM edits proposal that I'm working on. Sigh.
>
>
> > > void* svGetUserData(svScope scope, void* userKey);
> >
> > MICHAEL:
> > define the return value NULL for an invalid scope or key
>
>
> No!!!! NULL may be a valid user's value. ("Have I already
> allocated my C data
> associated with that scope? NULL if not allocated yet.")
>
>
> This reminds me that the description of svGetUserData(), and
> of all "get"
> functions coupled with "put" function, should define what
> will be the initial
> value, i.e. what "get" returns if called prior to "put".
> NULL/zero seems a natural candidate.
DOUG: Took care of this suggestion in my LRM edits mail.
>
>
> Andrzej
>
This archive was generated by hypermail 2b28 : Thu Mar 27 2003 - 11:43:38 PST