> 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://stat.ethz.ch/mailman/listinfo/r-devel
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>-- Herv? Pag?s Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fredhutch.org Phone: (206) 667-5791 Fax: (206) 667-1319
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= >> >> >