similar to: Error compiling 87283 on Windows 10 using Rtools4.4 6335-6327

On 10/31/24 18:35, Avraham Adler wrote: > On Thu, Oct 31, 2024 at 12:42?PM Tomas Kalibera > <tomas.kalibera at gmail.com> wrote: >> On 10/31/24 17:30, Avraham Adler wrote: >>> When compiling R, the build fails after byte compiling grDevices with >>> the following error: >>> >>> byte-compiling package 'grDevices' >>> make[4]:

R version 1.0.1 OS RedHat Linux 6.1 In attempting to test for numeric vectors in a data frame, I tried: apply(dataframe,2,is.numeric) and found that it returned FALSE for all vectors whether they were numeric or not. I tracked this to the fact that as.array() was converting the data frame to character vectors, and thought I could solve it by using array(), which preserved the mode of the

On 4/24/25 00:18, Michael Chirico wrote: > In that case it seems like just erroring instead of returning invalid > pointers is a much friendlier option. Why give developers an unpinned > grenade to carry around? That would be too strict at this point. There is too much code around depending on that holding on to an invalid pointer (but not dereferencing it) is ok, and it is currently

The literanger package is no longer passing on CRAN (https://CRAN.R-project.org/package=literanger) due to array-bound warnings in GCC 13.3 and 14.2 (more details below). This _looks_ to me like one of either a) a compiler bug, b) a false positive, or c) (very unlikely) something in the standard library implementation. Have others seen warnings like this recently, and if so, what have you done

I am trying to submit a package on CRAN, and everything passes ok on all platforms but Debian, where CRAN responds with an automatic "significant" warning: * checking whether package ?QCA? can be installed ... [35s/35s] WARNING Found the following significant warnings: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ?__builtin_strncpy? output may be truncated

I'm not sure if this is a GCC bug or a bug in our code, but the attached workaround fixes it for me. Rich.

? Fri, 9 May 2025 11:09:22 +1000 Stephen Wade <stephematician at gmail.com> ?????: > inlined from ?std::vector<double> literanger::adjust_pvalues(const > std::vector<double>&)? at ../src/literanger/utility_math.h:99:48: > /usr/include/c++/13/bits/stl_algobase.h:437:30: warning: ?void* > __builtin_memmove(void*, const void*, long unsigned int)? writing >

With the -Wformat-truncation warnings fixed, finish the job started in commit a61ddb4393ad ("drm: enable (most) W=1 warnings by default across the subsystem"), and enable that warning too. Signed-off-by: Jani Nikula <jani.nikula at intel.com> --- Gut feeling says there are more issues, and my configs just don't catch them all, but let's see what the build bots have to

>From R 4.5.0 [1], all builds of R discourage use of INTEGER() [and friends REAL(), ... and *_RO() equivalents] on length-0 SEXP [2]. Before R 4.5.0, this was the behavior under --enable-strict-barrier. That means the following can segfault under strict builds (e.g. -fsanitize=alignment and -O0): SEXP x = PROTECT(Rf_allocVector(INTSXP, 0)); SEXP y = PROTECT(Rf_allocVector(INTSXP, 0)); const

Hopefully a member of the CRAN team will tell me I'm wrong, but I think whether or not there is a compiler bug is ultimately irrelevant -- packages on CRAN must compile cleanly even with potentially-buggy development versions of compilers. So, whether or not there is a bug in gcc is moot -- you'll need to find a way to avoid triggering this issue in your package code. Best, Kevin On

Hi Jani, On Thu, May 23, 2024 at 06:51:09PM +0300, Jani Nikula wrote: > With the -Wformat-truncation warnings fixed, finish the job started in > commit a61ddb4393ad ("drm: enable (most) W=1 warnings by default across > the subsystem"), and enable that warning too. > > Signed-off-by: Jani Nikula <jani.nikula at intel.com> When it is enabled for all of drm then the

On Thu, Sep 24, 2020 at 2:58 PM Ján Tomko <jtomko@redhat.com> wrote: > On a Thursday in 2020, Wei Wang wrote: > >Seems it didn't appear on the mailing list, resent it. > > > > Hi folks, > > > >I'm trying to build libvirt using meson with the latest upstream libvirt, > >but the compilation fails: > >(followed on

On 5/9/25 03:09, Stephen Wade wrote: > The literanger package is no longer passing on CRAN > (https://CRAN.R-project.org/package=literanger) due to array-bound > warnings in GCC 13.3 and 14.2 (more details below). > > This _looks_ to me like one of either a) a compiler bug, b) a false > positive, or c) (very unlikely) something in the standard library > implementation. >

Both Coverity and GCC with -Wstringop-overflow noticed that nvif_outp_acquire_dp() accidentally defined its second argument with 1 additional element: drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_pior_atomic_enable': drivers/gpu/drm/nouveau/dispnv50/disp.c:1813:17: error: 'nvif_outp_acquire_dp' accessing 16 bytes in a region of size 15 [-Werror=stringop-overflow=]

https://bugzilla.mindrot.org/show_bug.cgi?id=3578 Bug ID: 3578 Summary: RFE: forward error correction Product: Portable OpenSSH Version: 9.3p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

Sorry! I've been pretty busy until now, this is: Reviewed-by: Lyude Paul <lyude at redhat.com> Let me know if you've pushed it already or if you want me to push it to drm- misc On Wed, 2023-01-25 at 12:15 -0800, Kees Cook wrote: > Ping. I'll take this via my tree unless someone else wants to take it... > > On Sun, Nov 27, 2022 at 10:30:41AM -0800, Kees Cook wrote:

*//* Hi Denis, Il 06/02/2018 20:05, Denis Cardon via samba ha scritto: > Hi Massimo, > >> Il 05/02/2018 16:41, Rowland Penny ha scritto: >>> On Mon, 5 Feb 2018 16:01:27 +0100 >>> "Massimo Donato - Adcom.it via samba" <samba at lists.samba.org> wrote: >>> >>>> */Hi all, >>>>      after a couple of year of successfully

When I try to unlist a very large list, R is killed without any other warning: A<-as.list(as.data.frame(matrix(1:21639744,nrow=3578,ncol=6048))) with AA<-unlist(A) or AA<-c(A,recursive=TRUE) I get a R terminado (killed) and the end of the session. I think I'll need to get more RAM (now 1Gb, any other solutions welcomed) to be able to do this but, shouldn't I get a more gentle

> On 23 Nov 2015, at 22:30 , aixtools <aixtools at gmail.com> wrote: > >> >> ./configure --enable-maintainer-mode ... Two things here - possibly irrelevant, but I'd avoid building in the source directory. (mkdir ../BUILD ; cd ../BUILD; ../R/configure) - don't turn on mantainer mode. You are not a maintainer, and if you want to play at being one, I think you

termplot() does not carry subsetting over to carriers that are in the environment but not in the data frame. This generates a "subscript out of bounds" error. > data(ToothGrowth) > logdose <- log(ToothGrowth$dose) > tooth.lm <- lm(len ~ logdose, data=ToothGrowth) > termplot(tooth.lm) ## Works fine > toothVC2.lm <- lm(len ~ poly(dose,2),