search for: longints

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? Regards Ben

> 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

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

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

On 15 August 2018 at 20:32, Benjamin Tyner wrote: | 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). As Bill Dunlap already told you, this is a) ancient and b) was concerned with the int as 16 bit to 32 bit transition period. Ie a long time ago. Old C

On 16/08/2018 18:33, Herv? Pag?s wrote: > On 08/16/2018 05:12 AM, Dirk Eddelbuettel wrote: >> >> On 15 August 2018 at 20:32, Benjamin Tyner wrote: >> | 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

On 08/16/2018 05:12 AM, Dirk Eddelbuettel wrote: > > On 15 August 2018 at 20:32, Benjamin Tyner wrote: > | 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). > > As Bill Dunlap already told you, this is a) ancient and

FYI, looks like support for Racoon is ending. Does anyone have any experience with the version in ipsec-tools ? ---Mike >Racoon users, > >This is the announcement that the kame project will quit providing >a key management daemon, the racoon, and that "ipsec-tools" will become >the formal team to release the racoon. >The final release of the racoon in the

Thanks for your help with this problem about dynamic linked libraries. I thought I had it solved, but apparently not. Below is a small piece of Pascal code that I compile into a library. When I load the library using dyn.load R becomes very unstable. The Mac GUI crashes in all kinds of situations --even moving a window can sometimes crash it. Running from the command line (I thought the

http://usor.lerao.com/ username:demo password:demo I have been working on this for about two months for the University of Cincinnati. We are planning on releasing the project open source when it is more complete. I need to port alot of things to a more general way of doing things and refactor alot of code so this should get better daily. There are some prieview images at my blog

Hi all, may I request the following two changes to Rdefines.h (R 0.65.1)? 1.) Change line 106 from #define Free(p) R_chk_free( (void *)(p) ) to #define Free(p) R_chk_free( (void *)(p) ) , p=NULL 2.) Add after line 79: #define PROBLEM {char R_problem_buf[R_PROBLEM_BUFSIZE];sprintf(R_problem_buf, a new line 80: #define PROBLEM {char

Appologies for cross-posting Dear R users, I am using R2WinBUGS to call WinBUGS from R. After loading data, model, and initial values I call this command res <- bugs(data = dfile, inits = list(ifile), parameters.to.save = c("beta"), model.file = mfile, working.directory = tdir, n.thin = nthin, n.chains = 1, n.iter = niterations*nthin, n.burnin = 0, DIC = F, debug = T,

Hi, I'm writing to ask what is the reason that a Trap window always pops up in WinBUGS? I'm tring to run the function 'bugs' in R for a zero-inflated gaussian model. The contents appear in the Trap window is as follows: *incompatible copy BugsCmds.TextError [000003A1H] .beg INTEGER 1636169112 .end INTEGER 16861596 .name ARRAY 256 OF CHAR

Dear all, I'm calling Winbugs (1.4.3) through R2WinBugs (2.1-18 coda_0.14-7) to fit a switching random walk model, but come up with an instant trap with the log only displaying 'check('. I will paste the trap with session info below; I'd be very grateful for any ideas. Couple of leads: 1. I presume the problem relates to the r package itself or the way I call bugs(), because I

>>> >>> Those are valid instructions in every x86-32 assembler I'm aware of. >>> Perhaps it needs a switch to put it in 32-bit mode? >> >> Yes, I have been able to confirm that's what's happening behind the >> scene. The switch would be --32, however after that, ld will try to >> link >> the 64-bit versions of libc and the C

I do not know the configury stuff well enough to answer this, can someone else help? On Feb 28, 2008, at 1:55 AM, Joachim Durchholz wrote: > Am Mittwoch, den 27.02.2008, 14:31 -0800 schrieb Dale Johannesen: >> On Feb 27, 2008, at 2:12 PM, Joachim Durchholz wrote: >>> All error messages refer to one of the following four >>> instructions: >>> pushl %ebp