On 29 =ED=C1=CA, 18:58, James Kuyper <jameskuy...@[EMAIL PROTECTED]
> wrote:
> angel_tsankov wrote:
> > On 23 =ED=C1=CA, 23:57, jameskuy...@[EMAIL PROTECTED]
wrote:
> ...
> >> What you need to do is be more specific about what precisely is
> >> prohibited. I gather that you want it to be prohibited at compile
> >> time, so that code with behavior that is otherwise well-defined and
> >> which compiles without diagnostics is guaranteed to never generate a
> >>nullvalue for an unnullablepointer. In standardese, that means that
> >> any problematic code must be either a syntax error or a constraint
> >> violation, and it doesn't seem feasible to me to make these syntax
> >> errors.
>
> > Why? Could you sup****t your point with some more details or examples?
>
> Simplest example:
>
> void func(char *p)
> {
> unnullable char *q=3Dp;
> // Code which uses q, relying upon it not beingnull.
>
> }
>
> Code like this would have to be prohibited, since 'p' might benull.
Yes, implicit conversion from a nullable pointer to a unnullable would
be prohibited. However, there might be a reason for explicit
conversion:
void func(char *p)
{
if (p !=3D NULL)
{
unnullable char* r =3D (unnullable char*)q;
// ...
}
}
> However, it's very difficult to write a rule that prohibits such code by
> making it a syntax error. If you think otherwise, please provide grammar
> rules that express that idea. On the other hand, it's easy to express
> such a prohibition as a violation of a constraint, one that requires
> that the initializer for an unnullablepointerbe an expression with a
> nullablepointertype.
>
> >> It would also have to be constraint violation for an
> >> object with an unnullablepointertype to be left uninitialized. As a
> >> result, I don't think it would be feasible to allow the space
> >> containing an unnullablepointerobject to be allocated using the
> >> malloc() family.
>
> > One could have malloc2(), taking an unnullablepointerthat would
> > serve as initilizer for the malloc'ed unnullablepointer.
>
> The C standard currently allows for the possibility that pointers to
> different types can have different representations, and even different
> sizes. There are a number of good reasons why many real-world
> implementations actually use two or more differentpointer
> representations, depending upon the type of the object being pointed at.
> How could such an implementation implement malloc2() so it would know
> which representation to use? It would be relatively straightforward to
> handle that case by making malloc2() a C++ template function, but I
> don't see any easy way to do it in C.
I do not really get your point here... As far as I know malloc does
not care about types - it only cares about allocating memory of the
specified amount.
> Would it be prohibited for a structure to contain a member of
unnullablepo=
intertype? If not, how do you tell malloc2() where to insert
thepointerthat =
it takes as an argument, when allocating space for such a
> structure?
> Could you allocate an array of unnullable pointers? Does that mean that
> malloc2() would have to be prepared to accept an unlimited number
ofpointe=
rarguments as initializers, presumably by using a <varargs.h>
> interface? Or would it initialize all of them to point at the same
> object, and let them be reassigned later? Unlike the previous issues,
> this one has at least two different perfectly feasible solutions; but
> you'll have to choose one.
Automatic arrays would either be randomly initialized or prohibited.
> >> The address-of operator (&) would have to have a value which is
> >> neither nullable nor unnullable, but usable for either purpose; the
> >> initializer for an object with an unnullablepointertype would have
> >> to be the address of an lvalue expression. You'd need a special case
> >> to disallow
>
> >> unnullable char* p =3D &*(char*)0;
>
> > This code is undefined behaviour - *(char*)0.
>
> No, it does not. The expression "*(char*)0", if it were to occur in most
> other contexts, would have undefined behavior. However, section
> 6.5.3.2p3, describing the '&' operator, says "If the operand is the
> result of a unary * operator, neither that operator nor the & operator
> is evaluated and the result is as if both were omitted,". In other
> words, &*(char*)0 is equivalent to (char*)0, which has perfectly
> well-defined behavior, even though *(char*)0 would have undefined
> behavior in any other context.
Ooops, sorry. I think initialization with constant expressions should
be prohibited, too. In fact, it would only be possible to initialize
an unnullable pointer fron an object, just like references in C++.
This is a bare minimum; it could be extended, if needed.
> --
> comp.lang.c.moderated - moderation address: c...@[EMAIL PROTECTED]
-- you
must
> have an appropriate newsgroups line in your header for your mail to be
see=
n,
> or the newsgroup name in square brackets in the subject line. Sorry.
--
comp.lang.c.moderated - moderation address: clcm@[EMAIL PROTECTED]
-- you must
have an appropriate newsgroups line in your header for your mail to be
seen,
or the newsgroup name in square brackets in the subject line. Sorry.
|
