Functions that CRAN disallows

[szhorvat]

@Gabor The igraph C sources have many parts disabled with #ifndef USING_R.

I assume this is motivated by CRAN not allowing functions that exit (abort()) or printing to the terminal (stdout, stderr).

These rules are of course reasonable not only for R but for all the high-level igraph interfaces. But having all this USING_R is inconvenient and error-prone.

Thus, my question is: What are the exact rules of CRAN? Do they really not allow these symbols to be even referenced in any of the object files? The public guidelines simply say not to call these functions, but don’t explicitly forbid referencing them. An example is igraph’s error handler: the R interface sets its own error handler anyway. Having to comment out all the default handlers is pointless and inconvenient. Who can we clarify the requirements with?

CC @vtraag @tamas since we’re been discussing this this morning.

[Gabor]

@szhorvat

But having all this USING_R is inconvenient and error-prone.

Why is this error prone? If you need to do compile time config, how else would you do it?

@szhorvat

Thus, my question is: What are the exact rules of CRAN?

The package has to pass R CMD check with CRAN’s configs.

@szhorvat

but don’t explicitly forbid referencing them

R CMD check checks the shared lib of the package and fails if it includes them. Why do you think I made an effort to remove them? It is particularly annoying to remove them from the flex/bison generated files.

@szhorvat

the R interface sets its own error handler anyway.

I am not sure how that is relevant, that does not use abort() etc, but throws an R error.

@szhorvat

Having to comment out all the default handlers is pointless and inconvenient.

Well, we don’t get to make the CRAN rules. If you want to update the package on CRAN, you need to follow the rules. Frankly, arguing with CRAN is pointless and a waste of time. They don’t have a way to exclude false positives from their checks, so we need to work around them.

[szhorvat]

@Gabor

Why is this error prone? If you need to do compile time config, how else would you do it?

It is error prone because it makes me touch R specific code when I am working on the C library.

---

This all came up while I was implementing fatal error handlers:

Implement fatal error handling

To make a long story short, I needed something that doesn’t return to make the compiler happy about the “noreturn” attribute. This would normally be an abort(). It would never get called if the rest of the code is correct, but in this situation the compiler had no way to determine that, so it gave a warning. Since we now use -Werror, it got inconvenient.

In the end, I used exit() from R.h, but didn’t have the chance to actually test this yet (updating the R interface to use the new cmake build system is going to take a while).

Implement fatal error handling

One could also use while (1) {} but that’s just nasty.

---

@Gabor

I am not sure how that is relevant, that does not use abort() etc, but throws an R error.

My point was that the R interface never makes a call to abort() even if functions that reference abort() are left in.

---

@Gabor

Well, we don’t get to make the CRAN rules. If you want to update the package on CRAN, you need to follow the rules. Frankly, arguing with CRAN is pointless and a waste of time. They don’t have a way to exclude false positives from their checks, so we need to work around them.

I guess there’s not much we can do, but I really do wonder how a lot of useful C packages even make it into R if the rules effectively require anyone who would want to create an R interface to them to do invasive patching …

[Gabor]

@szhorvat

It is error prone because it makes me touch R specific code when I am working on the C library.

Well, R does not need any error handler, so all that can be in #ifdef USING_R. Alternatively you can refactor the code so that the (default) error handlers of the C library are defined in a separate file, which we’ll leave out from the R interface.

Another way would be to not include any R specific code in the C library, and have a patch that is applied for creating the C code of the R package. I find this a lot more error prone, though.

@szhorvat

In the end, I used exit() from R.h ,

I don’t think there is exit() in R.h, and you should not call the exit() libc function.

@szhorvat

I guess there’s not much we can do, but I really do wonder how a lot of useful C packages even make it into R if the rules effectively require anyone who would want to create an R interface to them to do invasive patching …

Most packages don’t embed libraries but link to them, and these rules do not apply to the linked libraries.

[szhorvat]

There isn’t exit. I’m tired and I meant to type error. It is marked as noreturn , so it served the purpose.

I see that th elinks above are broken, here’s a good link:

igraph/igraph/blob/develop/src/igraph_error.c#L54