[R-pkg-devel] Frictionless alternative for `-Wstrict-prototypes`

[Lionel Henry]

Davis Vaughan and I were looking into the `-Wstrict-prototypes`
warnings for C code that were recently added to the R-devel checks. We
did a little research and found that these warnings are intended to
catch old-style definitions and declarations that were deprecated a
long time ago. This includes:

1. Unspecified types like `void fn(x, y);`
2. Unspecified parameter lists like `void fn();`.

We also found:

- That only unspecified types (case 1) will become defunct. For
  unspecified parameter lists (case 2), it was announced recently that
  the C standard committee has decided to simply change the meaning to
  "no arguments" in C23. This aligns with what most people think it
  means, and is what C++ does. See item 13 of page 130 in the C23
  working draft at https://open-std.org/JTC1/SC22/WG14/www/docs/n3054.pdf.

- The new `-Wdeprecated-non-prototype` option for clang-15 does not
  warn for empty parameter lists, allowing for a smooth transition
  that allows this widespread usage.

Since the no arguments case is both incredibly common and will become
fully legal C syntax in a close future, it seems it might not be worth
it to require all packages to update their code to an intermediary
form that reads less well, is not as intuitive to most people (and so
might crop up back in further updates), and will become standard in
the future anyway.

Perhaps a good course of action would be:

- Using `-Wno-strict-prototypes` to disable the stringent checks.

- Enabling the new `-Wdeprecated-non-prototype` in clang to catch
  old-style definitions and declarations.

This way CRAN would be able to catch deprecated syntax while allowing
the soon-to-be-legal syntax of empty parameter lists. We hope that
this would mean less code churn on CRAN, which means less work for the
CRAN maintainers as well as for the maintainers of CRAN packages.

Best,
Lionel & Davis

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Error when install binary from CRAN but not if install from source - Macintoh, lme4, Matrix, buildmer

[Carl Schwarz]

Yes, the resubmission and re-building has fixed the problem with buildmer/
Matrix.
Carl

On Tue, Oct 18, 2022 at 12:17 PM Duncan Murdoch 
wrote:

> I see the same thing.  This sounds like a problem in the handling of
> methods that has been discussed somewhat recently:
>
>https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html
>
> The problem is that when the binary is built, some code from other
> packages is kept as part of it.  When that other package is updated, you
> need a new source install of your own package (or a rebuild at CRAN to
> replace the binary) to cache the new code.
>
> This can also be done explicitly by package startup code; I think this
> thread
>
>https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008481.html
>
> turned out to be a case where rstan was caching something, and an update
> to ggplot2 didn't work with the cached data.  Given the error message,
> your issue sounds more like the first one.
>
> I don't recall if there was a resolution.  Maybe you can ask the CRAN
> maintainers to rebuild buildmer.
>
> Duncan Murdoch
>
>
>
>
>
> On 18/10/2022 2:51 p.m., Carl Schwarz wrote:
> > I've run into a problem where if you install the lme4, Matrix, and
> buildmer
> > packages using the binaries from CRAN on a Mac, I get an error message
> > about a missing method, but if I install the same packages from SOURCE,
> the
> > code runs fine.
> >
> > I would have thought that installing from source or using the binary
> > should look the same.
> >
> > Any suggestions on how to proceed to resolve this issue?
> >
> > The maintainer of buildmer is also puzzled.
> > You can follow the issue in more detail at:
> >  https://github.com/cvoeten/buildmer/issues/20
> >
> > This is way above my paygrade...
> >
> > Carl Schwarz
> >
> > --
> >
> > Tried this on an intel-Mac and arm-Mac with the same result.
> > Works fine on Windows machines under both scenarios.
> >
> > Here is a test example
> >
> > library(buildmer)
> > library(lme4)
> >
> > nrow <- 100
> >
> > test <- data.frame(x01=runif(nrow),
> > y=runif(nrow)<.1,
> block=as.factor(floor((1:nrow)/50)))
> > head(test)
> >
> >
> > fit.model <- lme4::glmer(y~x01 + (1|block), data=test,
> > family=binomial(link="logit"))
> > fit.model # this works
> >
> > class(fit.model)
> >
> > summary(fit.model)
> > # gives the following error message
> > Error in diag(from, names = FALSE) : object 'dgeMatrix_getDiag' not found
> >
> > A pdf document showing output is attached (shows the sessionInfo etc).
> >
> > When you install the buildmer and Matrix packages from SOURCE, it runs
> fine.
> >
> > I've tried all combinations of installing binary/source and only if both
> > packages (Matrix and buidmer) are installed from source, does the code
> run.
> >
> > Same issue on an intel-Mac.
> > Same issue when running under the R directly rather than Rstudio on a
> Mac.
> >
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel