Re: [Libclc-developers] Re: libclc questions

[Hallvard B F. <h.b...@us...>]

Michael B.Allen writes:
>Bj=F8rn Augestad <bo...@me...> wrote:
>
>>
>> Seriously, malloc is not, prior to e.g. Unix98, required to set errn=
o to=20
>> ENOMEM. This means that we cannot assume that errno contains a=20
>> reasonable value if malloc() fails. We must therefore set it ourselv=
es.=20
>> Since we don't know about POSIX (we're pure ANSI C, remember) we mus=
t=20
> > set it to CLC_ENOMEM. Oh well...
>=20
> But the standards do not say that malloc will not set errno to
> ENOMEM and every malloc ever written _does_ use ENOMEM.

Prove it.

> Same goes for probably every other ISO function you'll use.

fgetpos() can return ESPIPE (file descriptor is a pipe, FIFO, or socket=
)
on my system (Solaris).  Do you think that can happen on systems that d=
o
not support pipes?

> You're introducing a technically unncessary level of indirection that=

> contributes to an overall non-standard experience for the sake of a
> standard. Why are you going to make 99.9999% of the users deal with
> two different namespaces of error codes for some imaginary platform
> that doesn't exist?  Following the letter of the law for this is just=

> being pedantic.

So far, we don't know if we'll be using any CLC_E* error codes.  There
is little point in setting errno =3D CLC_ENOMEM in a function which can=

only return one type of error, for example.  Then all the user needs it=

to test whether or not an error happened.

The main point so far is that we want a standardized way which function=
s
can return error conditions if they want to.  We could have said that
such functions return an integer error code.  We chose not to; we
preferred to reuse the errno mechanism which already exists.  Given
that, we _had_ to open for the possibility that functions may need to
set errno to something which does not exist in any errno.h.

When libclc is nearing completion, maybe you'll be right and it'll turn=

out that almost no functions used this capability.  If so, _that_ is th=
e
time to discuss whether or not to remove CLC_E* codes.  Until then we
need them, to make sure clc functions return error conditions in a
consistent manner.

--=20
Hallvard