From btyner @ending from gm@il@com  Thu Aug 16 02:32:14 2018
From: btyner @ending from gm@il@com (Benjamin Tyner)
Date: Wed, 15 Aug 2018 20:32:14 -0400
Subject: [Rd] longint
In-Reply-To: <1608bafb-374d-1953-7694-de44e3ce9007@fredhutch.org>
References: <b8cc39c0-2e5b-2157-173b-7341ab687188@gmail.com>
 <2f3f2125-2cb1-51b8-a5ec-9986a18e698b@gmail.com>
 <B6423F6B-A085-444B-9119-6B09B9349F78@stats.ox.ac.uk>
 <1608bafb-374d-1953-7694-de44e3ce9007@fredhutch.org>
Message-ID: <7238fd29-6008-c32a-2446-8b6f534b77fd@gmail.com>

Thanks for the replies and for confirming my suspicion.

Interestingly, src/include/S.h uses a trick:

 ?? #define longint int

and so does the nlme package (within src/init.c).

On 08/15/2018 02:47 PM, Herv? Pag?s wrote:
> No segfault but a BIG warning from the compiler. That's because 
> dereferencing the pointer inside your myfunc() function will
> produce an int that is not predictable i.e. it is system-dependent.
> Its value will depend on sizeof(long int) (which is not
> guaranteed to be 8) and on the endianness of the system.
>
> Also if the pointer you pass in the call to the function is
> an array of long ints, then pointer arithmetic inside your myfunc()
> won't necessarily take you to the array element that you'd expect.
>
> Note that there are very specific situations where you can actually
> do this kind of things e.g. in the context of writing a callback
> function to pass to qsort(). See 'man 3 qsort' if you are on a Unix
> system. In that case pointers to void and explicit casts should
> be used. If done properly, this is portable code and the compiler won't
> issue warnings.
>
> H.
>
>
> On 08/15/2018 07:05 AM, Brian Ripley wrote:
>>
>>
>>> On 15 Aug 2018, at 12:48, Duncan Murdoch <murdoch.duncan at gmail.com> 
>>> wrote:
>>>
>>>> On 15/08/2018 7:08 AM, Benjamin Tyner wrote:
>>>> Hi
>>>> In my R package, imagine I have a C function defined:
>>>> ???? void myfunc(int *x) {
>>>> ??????? // some code
>>>> ???? }
>>>> but when I call it, I pass it a pointer to a longint instead of a
>>>> pointer to an int. Could this practice potentially result in a 
>>>> segfault?
>>>
>>> I don't think the passing would cause a segfault, but "some code" 
>>> might be expecting a positive number, and due to the type error you 
>>> could pass in a positive longint and have it interpreted as a 
>>> negative int.
>>
>> Are you thinking only of a little-endian system?? A 32-bit lookup of 
>> a pointer to a 64-bit area could read the wrong half and get a 
>> completely different value.
>>
>>>
>>> Duncan Murdoch
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwIFAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=ERck0y30d00Np6hqTNYfjusx1beZim0OrKe9O4vkUxU&s=x1gI9ACZol7WbaWQ7Ocv60csJFJClZotWkJIMwUdjIc&e= 
>>>
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwIFAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=ERck0y30d00Np6hqTNYfjusx1beZim0OrKe9O4vkUxU&s=x1gI9ACZol7WbaWQ7Ocv60csJFJClZotWkJIMwUdjIc&e= 
>>
>>
>



[Rd] longint
Benjamin Tyner