[IBIS] RE: BIRD137: AMI_parameters_in, AMI_parameters_out, msg Clarifications

Radek,

Regarding "I question the need for sending back an empty string", I remember
someone stating that this would be useful for existing models
which may do that.

Regarding the minutes, I don't see anything in it that says that
the double quotes are passed to the DLL as being the empty string.
The sentence towards the end of this section of the minutes:
"Arpad added that an empty string could be a /0 in C or a ""." is not worded to
well, because it could be interpreted as the double quotes being
passed to the DLL as the empty string, but that is not what I
meant when I said it.

Either way, I think the problem is that we do not formally define
a lot of things in the spec (note Mike L.'s comments on the
Boolean True/False in BIRD 135). I think the spec should have a
definitions section somewhere towards the beginning, and in the
later parts of the spec we shouldn't have to spell out definitions.
For this reason I would say that we should leave this BIRD as is,
and write another BIRD to define what "empty string" is, or add
that topic to BIRD 127.1.

Thanks,

Arpad
===================================================================

From: radek_biernacki@agilent.com [mailto:radek_biernacki@agilent.com]
Sent: Friday, July 15, 2011 2:09 AM
To: Muranyi, Arpad; ibis@eda.org
Subject: RE: BIRD137: AMI_parameters_in, AMI_parameters_out, msg Clarifications

Hi Arpad,

You need to take a look at the minutes of the last meeting to recall the discussions. The gist of the discussion is there.

My point is that we need to be 100% precise, and currently we are not.

I believe the issue of whether the entire string "in" and "out" can or cannot be encompassed within the quotes was raised at some point, but I do recall any action on that. Of course, I agree, this should not be allowed, but I also believe we do not say that. Your reference to string literals is about a completely different issue - this is about string values within the tree.

If you read my e-mail carefully, I question the need for sending back an empty string, but if you insist on retaining this option all I ask is to clearly state what the empty string is.

Finally, my point in "a similar interpretation ..." is that if we are not 100% precise then we leave room for interpretations, even those that we may feel unlikely.

Radek

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi, Arpad
Sent: Thursday, July 14, 2011 10:35 PM
To: ibis@eda.org
Subject: [IBIS] RE: BIRD137: AMI_parameters_in, AMI_parameters_out, msg Clarifications

Radek,

First, I don't remember hearing in the last teleconference that
"...where the DLL returns a valid pointer to a string that has two characters - the
opening and closing quotes". Even if this was mentioned by someone,
it is wrong, it can't happen. The definition of string in the
current IBIS spec (5.0) is (pg. 141):

| ... String
| literals begin and end with a double quote (") and no double quotes are
| allowed inside the string literals.

My understanding is that when the EDA tool passes a string
parameter to the DLL, it doesn't pass the double quotes
along with the string, only the content between the quotes.
So when I say empty string in BIRD 137, I mean that there
is nothing between the double quotes, and only that nothing
is passed to the DLL, without the double quotes. After
compilation this would end up being a null terminated
sequence of characters in which there is nothing else but
the null termination \0. This BIRD doesn't suggest to
include the double quotes in the empty string. The double
quotes are only there to enclose the string because it is
a string, but if there is nothing between the double quotes,
the string is empty.

Regarding "a similar interpretation could be extended to any string that
consists of any number of white spaces, tabs, line termination characters,
regardless of whether the first and last characters are quotes or not.", as
far as I can tell, in the more modern programming languages
it is pretty clear that an empty string is empty, i.e.
doesn't contain a bunch of spaces, tabs, etc... I do not
understand why you brought this topic up.

For this reason I really don't see that there is a problem.

Since I am not a programming expert, I am willing to learn
and listen to suggestions, and if necessary make changes to
the BIRD, but at this point I simply don't see a problem.

Comments?

Thanks,

Arpad
===============================================================

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of radek_biernacki@agilent.com
Sent: Thursday, July 14, 2011 2:52 PM
To: michael.mirmak@intel.com; ibis@eda.org
Subject: [IBIS] RE: BIRD137: AMI_parameters_in, AMI_parameters_out, msg Clarifications

Hi Michael,

As BIRD 137 is scheduled for vote at tomorrow's IBIS Open Forum teleconference, I would like to state that I still have reservations about the vagueness of the term "empty string" as an option for returning "AMI_parameters_out" and "msg" parameters. The cleanest return value is the NULL pointer, whether reset by the DLL or left alone at the NULL value initialized by the EDA platform. The second option of returning a valid pointer at which '\0' is set would be ok if it were explicitly stated in the BIRD. The third option mentioned at the last teleconference, that is where the DLL returns a valid pointer to a string that has two characters - the opening and closing quotes - is the worst. Please note that a similar interpretation could be extended to any string that consists of any number of white spaces, tabs, line termination characters, regardless of whether the first and last characters are quotes or not.

I do not quite remember if we have already clarified whether the "in" and "out" strings are allowed to have the opening and closing quotes encompassing the entire tree, but assuming that such quotes are not allowed, the third option (with the quote characters) would be inconsistent with the general rules.

I suggest simply removing the references to the "empty strings" and to leave the first option as the only valid action.

Best regards,

Radek Biernacki
Agilent EEsof EDA

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Mirmak, Michael
Sent: Tuesday, June 21, 2011 4:30 PM
To: 'ibis@server.eda.org'
Subject: [IBIS] BIRD137: AMI_parameters_in, AMI_parameters_out, msg Clarifications

The enclosed BIRD 137, AMI_parameters_in, AMI_parameters_out, msg Clarifications, is posted on behalf of Arpad Muranyi of Mentor Graphics and Curtis Clark of Ansys. It will be discussed at the next IBIS Open Forum teleconference.

A complete list of BIRDs is available at http://www.eda.org/ibis/birds/.

Michael Mirmak
Intel Corp.
Chair, IBIS Open Forum

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993