RE: [lsb-futures] RE: [Lsb-wg] Library suitability

There is no spec.

It would have to be written.

--
Gordon McFadden
System Architect
Channel Software Operation
Intel Corporation
ph:   +1 503 264 4309
[email protected]

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Anthony Youngman
Sent: Friday, June 24, 2005 4:23 AM
To: Wichmann, Mats D; [email protected];
[email protected]
Subject: RE: [lsb-futures] RE: [Lsb-wg] Library suitability

I agree with the GIGO observation ... 

But having only seen your emails and not anybody else's, does the spec
say "*t is a VALID pointer", or does it say "*t is a pointer" (for which
NULL could be considered a valid value). In the latter case, is it the
function or the spec which is at fault?

Cheers,
Wol

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Wichmann, Mats D
Sent: 23 June 2005 18:17
To: McFadden, Gordon; [email protected];
[email protected]
Subject: [lsb-futures] RE: [Lsb-wg] Library suitability


	So I have a philosophical question.
 
	If we are considering a library for inclusion into one of our
spec's, do
	we care about how well or not the library is implemented.

	Example.  Say we come across the following function:

	int foo( struct bar *t)
	{
	      int y;

	      y = t->member + 3;
	      return y;
	}

	Since the function does not validate parameter *t, then passing
in a NULL (or 
	other illegal entries) will cause the function to sigfault.

	Is looking at such constructs outside the scope of our selection
criteria?

I think so.

Our criteria have to do with the API/ABI set, not with the innards
of a specific implementation. Of course, the ability of the only
existing implementation to pass the tests is a factor.

Stuff like the above I'd just feed back to the upstream project as
a concern, and can be expected to be part of the stuff we will
discover as we start turning over rocks in making something more
formal for inclusion in LSB.  For example, this happened with PAM,
and eventually the problems we found did get addressed in upstream.


_______________________________________________
lsb-futures mailing list
[email protected]
http://mail.freestandards.org/mailman/listinfo/lsb-futures


************************************************************************
****

This transmission is intended for the named recipient only. It may
contain private and confidential information. If this has come to you in
error you must not act on anything disclosed in it, nor must you copy
it, modify it, disseminate it in any way, or show it to anyone. Please
e-mail the sender to inform us of the transmission error or telephone
ECA International immediately and delete the e-mail from your
information system.

Telephone numbers for ECA International offices are: Sydney +61 (0)2
8272 5300, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New
York +1 212 582 2333.

************************************************************************
****


_______________________________________________
lsb-futures mailing list
[email protected]
http://mail.freestandards.org/mailman/listinfo/lsb-futures