Testing if a pointer is valid

[Michael Press]

Often you don't know how the app will be used. For instance a
spreadsheet might be used for an undergraduate research project, or it
might hold details of cancer patients in a drugs trial. The
requirements are the same.
Now lets say the program detects an invalid pointer. If it crashes
out, it destroys maybe six hours work by the undergraduate. That's a
major irritation. He won't use that package again and you've lost a
customer.

If he has not saved his work in six hours,
he learned a valuable lesson.

 

[Willem]

Michael Press wrote:
) If he has not saved his work in six hours,
) he learned a valuable lesson.

Indeed. He learned that he shouldn't buy software from your company.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Phil Carmody]

Is it time to recognize that you did not assert
consequences of dereferencability of a pointer
to its validity?

Is it time for you to post English that parses?

Phil

 

[Ben Bacarisse]

On 2011-09-22, Phil Carmody <[email protected]> wrote:

Is one permitted to ask why they didn't write
for (int x = 0; x < N;x++)
inverse_table[function_table[x]] = x;

yes i use that on one of my first programs in C
i don't know assembly traslation so don't know if it is right
[possible modify 2 times function_table[x] so could be not ok
to what i know]

Do you mean that you are not sure if the code is really proper C, with
no undefined behavour? If so, there's nothing to worry about: it's fine.

<snip>

 

[Michael Press]

Is it time for you to post English that parses?

Betcha one Galactic Federation dollar that it parses.

 

[Kleuskes & Moos]

Michael Press wrote:
) If he has not saved his work in six hours, ) he learned a valuable
lesson.

Indeed. He learned that he shouldn't buy software from your company.


SaSW, Willem

If those are your standards, you'll have trouble finding suppliers for most
desktop software. The level of testing and debugging you need in order to
provide that kind of stability just isn't economically viable for humdrum
applications. That's why testing is usually crowd-sourced by releasing
'beta-versions'. The problem with testing is that it can only show the
presence of bugs, not their absence, according to the Proverbs of Dijkstra.

Unless, of course you know of some way to get it right first time, every
time, which has eluded us mere mortals so far.

-------------------------------------------------------------------------------
_______________________________________
< We just joined the civil hair patrol! >
---------------------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------

 

[James Kuyper]

On Tue, 27 Sep 2011 02:06:19 +0100, Ben Bacarisse

I once saw some code that had to tabulate a function and it's inverse.
Both were permutations of the integers in the range 0..(N-1):

for (int x = 0; x < N; x++)
function_table[x] = /* relatively complex code */;

....
Is one permitted to ask why they didn't write
for (int x = 0; x < N;x++)
inverse_table[function_table[x]] = x;

or should one just appreciate it for the thing of beauty that it is?

Are you sure the function is a bijection? Or at least a surjection?

The function is described as having an inverse. The function and its
inverse are both described as permutations of the integers in the range
[0, N-1]. I'd have to think for a little while before putting together a
formal proof, but off-hand, that seems sufficient to guarantee that it's
a bijection. Am I missing something?

 

[Tim Rentsch]

For better or worse, I make a LOT of the kinds of mistakes that "only"
incompetent programmers make. I have fairly extreme ADHD, and the functional
upshot is that I can do a lot of things that are too hard for most people to
even attempt, but I can't do a lot of things that they take for granted,
because my brain simply *won't stay focused long enough* if a task isn't
Really Hard. If something isn't compelling enough to draw my whole attention
to it, I'm off thinking about unrelated things within a second or two.

I was going to post a really funny response to this,
but then I started thinking about something else...

 

[Tim Rentsch]

I don't think a reversible integer conversion is needed. You are always
permitted to manipulate an object via a pointer to char (well, any of
the three char types in fact) so can mask a pointer that way. You won't
be able to access the pointer without potential UB but that does not
matter for this example. I.e.

void *space = malloc(42);
for (size_t i = 0; i < sizeof space; i++)
((unsigned char *)&space) ^= 0xaa;

Any reference to 'space' now (let alone *space or anything like that) is
UB, but provided the code is repeated before any subsequent use, you're
OK.

I say "think" because I have a niggling doubt. If pointers have padding
bits I am not sure that these have to hold the last value stored in
them. The two xor's are then not guaranteed to return the pointer to
its initial state, and the result might be a trap representation. It
would be odd indeed -- the padding bits would have to change one way on
the first xor and in some other way on the second, but that might be
permitted. Of course, no padding bits and you are home and dry.

The standard only uses the term "padding bit" in reference to
integer representations. It doesn't say enough about pointer
representations for the concept to be meaningful.

That's true, but what it does say means that there can be bits that
might contribute to a trap representation but not to the value. Surely
that is effectively the same thing?

The two xors will return the pointer to its original
*representation*, and that has to be good enough to return it to
its original *value*.

My problem was with the first part. My worry was that, since only the
value is said to be retained, bits that do not contribute to the value
might change between the xors. However, that clause -- about an object
retaining its last stored value -- presumably applies equally to the
unsigned char objects written in the loop so there are no grounds for my
niggling doubt. [snip incidental]

The meaning of a "value stored in an object" is defined in 6.2.6.1p4
(and p3 for bit-field objects); it is exactly the N * CHAR_BIT bits
of the object, where N is the size of the object being stored into.
In other words, a "stored value" is just the object representation of
a value. That should clear up any doubts or confusion about changing
representations, flipping padding bits, etc.