thr3ads.net - R devel - [Rd] use of buffers in sprintf and snprintf [May 2019]

If this information is useful, please help other people find it:
Share via:

Ralf Stubner

2018-May-28 10:13 UTC

[Rd] readLines function with R >= 3.5.0

On 28.05.2018 11:07, G?bor Cs?rdi wrote:> stdin() is not the same as file("stdin"), see the note in ?stdin.
In particular stdin() works in an interactive session but not when R -f
/ Rscript is used, since it does not wait for the user to input anything:

$ R -f readLines.R

R version 3.5.0 (2018-04-23) -- "Joy in Playing"
Copyright (C) 2018 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
[...]> create_matrix <- function() {+   cat("Write the numbers of vertices: ")
+   user_input <- readLines(stdin(), n=1)
+   user_input <- as.numeric(user_input)
+   print(user_input)
+   }> create_matrix()
Write the numbers of vertices: numeric(0)>
>>>>>>> Martin Maechler
>>>>>>>     on Mon, 28 May 2018 10:28:01 +0200 writes:
>>     > It "works" if you additionally (the [Enter], i.e.,
EOL) you also
>>     > "send" an EOF -- in Unix alikes via  <Ctrl>-D
From my point of view this is a reasonable workaround for now.

Thanks
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustra?e 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stubner at daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966 P
Ust.-IdNr.: DE300072622
Gesch?ftsf?hrer: Prof. Dr. Dr. Karl-Kuno Kunze


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<https://stat.ethz.ch/pipermail/r-devel/attachments/20180528/945902d8/attachment.sig>

Martin Maechler

2018-May-28 14:38 UTC

head link

[Rd] readLines function with R >= 3.5.0

>>>>> Ralf Stubner 
>>>>>     on Mon, 28 May 2018 12:13:57 +0200 writes:
    > On 28.05.2018 11:07, G?bor Cs?rdi wrote:
    >> stdin() is not the same as file("stdin"), see the note in
?stdin.

Of course it is not the same, otherwise using one for the other
had no effect, but you are right:
it is *NOT* a solution to the problem

    > In particular stdin() works in an interactive session but not when R -f
    > / Rscript is used, since it does not wait for the user to input
anything:

    > $ R -f readLines.R

    > R version 3.5.0 (2018-04-23) -- "Joy in Playing"
    > Copyright (C) 2018 The R Foundation for Statistical Computing
    > Platform: x86_64-pc-linux-gnu (64-bit)
    > [...]
    >> create_matrix <- function() {
    > +   cat("Write the numbers of vertices: ")
    > +   user_input <- readLines(stdin(), n=1)
    > +   user_input <- as.numeric(user_input)
    > +   print(user_input)
    > +   }
    >> create_matrix()
    > Write the numbers of vertices: numeric(0)
    >> 

oh dear...  yes, that is true ..


    >>>>>>>> Martin Maechler
    >>>>>>>> on Mon, 28 May 2018 10:28:01 +0200 writes:
    >>> > It "works" if you additionally (the [Enter],
i.e., EOL) you also
    >>> > "send" an EOF -- in Unix alikes via 
<Ctrl>-D

    > From my point of view this is a reasonable workaround for now.

I'm glad to hear that.

Then, I now do think this needs to be dealt with as a bug
(but I'm not delving into fixing it!)

Martin


    > Thanks
    > Ralf

    > -- 
    > Ralf Stubner
    > Senior Software Engineer / Trainer

    > daqana GmbH
    > Dortustra?e 48
    > 14467 Potsdam

    > T: +49 331 23 61 93 11
    > F: +49 331 23 61 93 90
    > M: +49 162 20 91 196
    > Mail: ralf.stubner at daqana.com

    > Sitz: Potsdam
    > Register: AG Potsdam HRB 27966 P
    > Ust.-IdNr.: DE300072622
    > Gesch?ftsf?hrer: Prof. Dr. Dr. Karl-Kuno Kunze

    > x[DELETED ATTACHMENT signature.asc, application/pgp-signature]
    > ______________________________________________
    > R-devel at r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel

Ralf Stubner

2018-May-29 09:21 UTC

head link

[Rd] readLines function with R >= 3.5.0

On 28.05.2018 16:38, Martin Maechler wrote:> Then, I now do think this needs to be dealt with as a bug
> (but I'm not delving into fixing it!)
Ok. Can somebody with write privileges in bugzilla add the bug report? I
can also do this myself, if somebody with the required privileges can
create a user for me.

Greetings
Ralf

PS: I get an error message from https://bugs.r-project.org/bugzilla3/.

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustra?e 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stubner at daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966 P
Ust.-IdNr.: DE300072622
Gesch?ftsf?hrer: Prof. Dr. Dr. Karl-Kuno Kunze


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<https://stat.ethz.ch/pipermail/r-devel/attachments/20180529/b4819aa6/attachment.sig>

jing hua zhao

2019-May-29 15:49 UTC

head link

[Rd] use of buffers in sprintf and snprintf

Dear R-developers,

I am struggling with packaging with sprintf and snprintf() as the following
WARNINGS from gcc 9.x,

  hap_c.c:380:46: warning: ?%d? directive output may be truncated writing
between 1 and 10 bytes into a region of size between 0 and 127
[-Wformat-truncation=]
  hap_c.c:392:46: warning: ?%d? directive output may be truncated writing
between 1 and 10 bytes into a region of size between 0 and 127
[-Wformat-truncation=]

Essentially, I have

#define MAX_FILENAME_LEN 128
char of1name[MAX_FILENAME_LEN],of2name[MAX_FILENAME_LEN],
tempname[MAX_FILENAME_LEN];

...

 snprintf(tempname,sizeof(tempname),"%s.%d", of1name, j);

It looks I could get around with


#define MAX_FILENAME_LEN 128

#define MAX_FILENAME_LEN2 256

char of1name[MAX_FILENAME_LEN],of2name[MAX_FILENAME_LEN],
tempname[MAX_FILENAME_LEN2];

...
snprintf(tempname,2*sizeof(tempname)+1,"%s.%d", of1name, j)

It looks a bit waste of resources to me.


Any idea will be greatly appreciated,



Jing Hua

	[[alternative HTML version deleted]]

jing hua zhao

2019-May-30 14:54 UTC

head link

[Rd] use of buffers in sprintf and snprintf

Hi again,

I realised it is useful to replicate the warnings locally without relying on
CRAN automatic check; instead of R(-devel)  CMD check --as-cran
package_version.tar.gz one can use

R CMD check --configure-args=""

and in my case the WARNINGS were initially given with
https://www.stats.ox.ac.uk/pub/bdr/gcc9/README.txt and those specification might
as well used in --configure-args above.

Besst regards,


Jing Hua

________________________________
From: R-devel <r-devel-bounces at r-project.org> on behalf of jing hua
zhao <jinghuazhao at hotmail.com>
Sent: 29 May 2019 15:49
To: r-devel at r-project.org
Subject: [Rd] use of buffers in sprintf and snprintf

Dear R-developers,

I am struggling with packaging with sprintf and snprintf() as the following
WARNINGS from gcc 9.x,

  hap_c.c:380:46: warning: ?%d? directive output may be truncated writing
between 1 and 10 bytes into a region of size between 0 and 127
[-Wformat-truncation=]
  hap_c.c:392:46: warning: ?%d? directive output may be truncated writing
between 1 and 10 bytes into a region of size between 0 and 127
[-Wformat-truncation=]

Essentially, I have

#define MAX_FILENAME_LEN 128
char of1name[MAX_FILENAME_LEN],of2name[MAX_FILENAME_LEN],
tempname[MAX_FILENAME_LEN];

...

 snprintf(tempname,sizeof(tempname),"%s.%d", of1name, j);

It looks I could get around with


#define MAX_FILENAME_LEN 128

#define MAX_FILENAME_LEN2 256

char of1name[MAX_FILENAME_LEN],of2name[MAX_FILENAME_LEN],
tempname[MAX_FILENAME_LEN2];

...
snprintf(tempname,2*sizeof(tempname)+1,"%s.%d", of1name, j)

It looks a bit waste of resources to me.


Any idea will be greatly appreciated,



Jing Hua

        [[alternative HTML version deleted]]


	[[alternative HTML version deleted]]

Simon Urbanek

2019-May-31 02:20 UTC

head link

[Rd] use of buffers in sprintf and snprintf

No, that will make it even worse since you'll be declaring a lot more memory
that you actually have.

The real problem is that you're ignoring the truncation, so you probably
want to use something like

if (snprintf(tempname, sizeof(tempname), "%s.%d", of1name, j) >=
sizeof(tempname)) Rf_error("file name is too long");

BTW: most OSes systems have a path limits that are no lower than 256 so you
should allow at least as much.

Cheers,
Simon



> On May 29, 2019, at 11:49 AM, jing hua zhao <jinghuazhao at
hotmail.com> wrote:
> 
> Dear R-developers,
> 
> I am struggling with packaging with sprintf and snprintf() as the following
WARNINGS from gcc 9.x,
> 
>  hap_c.c:380:46: warning: ?%d? directive output may be truncated writing
between 1 and 10 bytes into a region of size between 0 and 127
[-Wformat-truncation=]
>  hap_c.c:392:46: warning: ?%d? directive output may be truncated writing
between 1 and 10 bytes into a region of size between 0 and 127
[-Wformat-truncation=]
> 
> Essentially, I have
> 
> #define MAX_FILENAME_LEN 128
> char of1name[MAX_FILENAME_LEN],of2name[MAX_FILENAME_LEN],
tempname[MAX_FILENAME_LEN];
> 
> ...
> 
> snprintf(tempname,sizeof(tempname),"%s.%d", of1name, j);
> 
> It looks I could get around with
> 
> 
> #define MAX_FILENAME_LEN 128
> 
> #define MAX_FILENAME_LEN2 256
> 
> char of1name[MAX_FILENAME_LEN],of2name[MAX_FILENAME_LEN],
tempname[MAX_FILENAME_LEN2];
> 
> ...
> snprintf(tempname,2*sizeof(tempname)+1,"%s.%d", of1name, j)
> 
> It looks a bit waste of resources to me.
> 
> 
> Any idea will be greatly appreciated,
> 
> 
> 
> Jing Hua
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

Possibly Parallel Threads

Search for more reasonably related threads

R devel - May 2019 - use of buffers in sprintf and snprintf

[Rd] readLines function with R >= 3.5.0

[Rd] readLines function with R >= 3.5.0

[Rd] readLines function with R >= 3.5.0

[Rd] use of buffers in sprintf and snprintf

[Rd] use of buffers in sprintf and snprintf

[Rd] use of buffers in sprintf and snprintf

Possibly Parallel Threads