Re: valid_pointer_p

[Kim F. Storm]

Eli Zaretskii <address@hidden> writes:

>> Cc: address@hidden
>> From: address@hidden (Kim F. Storm)
>> Date: Sun, 30 Jul 2006 02:05:25 +0200
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> > Can someone ``in the know'' please explain what clever idea is behind
>> > the function valid_pointer_p, and whether that idea is supposed to be
>> > portable?  
>> 
>> If you have some better way to do this on some platforms, please tell me.
>
> Well, I really don't understand what are the assumptions of the code.
> Are you assuming that accessing an invalid pointer inside a system
> call (such as `read') will never segfault?  Does Posix really mandate
> that?  

On the Linux kernel, write returns -1 with errno == EFAULT if the
provided buffer is invalid.

But, POSIX write spec does not say anything about invalid buffer or EFAULT.
So, indeed the current code is not portable.

>       Should we ask people to try that on different platforms?

IMO, it is not worth it.  This is a rare corner case.

> It goes without saying that on MS-Windows, the code does segfault if
> the argument is an invalid pointer.

.. but that's no worse than before I added pp / safe_debug_print.

And do people usually debug emacs with GDB on windows?

>
> As for other ways, we could, for example, set up a temporary signal
> handler for SIGSEGV around the call to valid_pointer_p.  That should
> work on most, if not all, supported platforms.
>
> Then there's the procfs API, which probably lets you actually read
> from the process memory on those platforms where procfs is available.
>
> On Windows, we could try reading from the address using the
> ReadProcessMemory API, which is used by debuggers.  (If ptrace allows
> reading from the calling process, we could do the same on Posix
> platforms.)

All of this sounds more or less complicated, but if someone want to
give one of these methods a try, fine with me.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk