Re: [hackers] [sbase] ed: Don't use strlcpy() || Roberto E. Vargas

2017-01-25 Thread Martin Kühne
...now now, don't hold contempt here. We're not one of *those* places.

cheers!
mar77i



Re: [hackers] [sbase] ed: Don't use strlcpy() || Roberto E. Vargas

2017-01-25 Thread ssd
* Laslo Hunhold 2017-01-24 21:56
> Roberto E. Vargas Caballero  wrote:
> 
> > You are considered harmful.
> 
> https://es.wikipedia.org/wiki/Argumento_ad_hominem
> 
> Come with real arguments next time. I honestly expected you to be more
> mature given your age.

hehe, utterly funny it is to complain about an ad hominem argument,
holier-than-thou, just to come up with an... ad hominem argument.

:o)

The link would have been enough.



Re: [hackers] [sbase] ed: Don't use strlcpy() || Roberto E. Vargas

2017-01-24 Thread Laslo Hunhold
On Tue, 24 Jan 2017 21:45:46 +0100
Roberto E. Vargas Caballero  wrote:

> You are considered harmful.

https://es.wikipedia.org/wiki/Argumento_ad_hominem

Come with real arguments next time. I honestly expected you to be more
mature given your age.

-- 
Laslo Hunhold 



Re: [hackers] [sbase] ed: Don't use strlcpy() || Roberto E. Vargas

2017-01-24 Thread Roberto E . Vargas Caballero
> I consider this way of thinking harmful, because it involves

You are considered harmful.

Regards,




Re: [hackers] [sbase] ed: Don't use strlcpy() || Roberto E. Vargas Caballero

2017-01-10 Thread Laslo Hunhold
On Tue, 10 Jan 2017 08:56:46 +0100 (CET)
g...@suckless.org wrote:

Hey Roberto,

> All the buffers related to files have FILENAME_MAX size, so it is
> impossible to have any buffer overrun.

I consider this way of thinking harmful, because it involves
assumptions about the code that are met in a different location. In
case FILENAME_MAX is changed to some strange value, this entire
building of thought breaks together.
There's no reason not to use strlcpy, as it saves you from buffer
overruns and other things. Nobody can possibly guarantee that some evil
input has a non-null-terminated fname and we write to savfname without
bounds.

As Dimitris likes to say, programs spend 99% with I/O, so this
"optimization" here won't make a difference. Premature optimization is
the root of all evil, and given we get strlcpy() for free from libutil,
I strongly suggest we keep the usage here.

Cheers

Laslo

-- 
Laslo Hunhold 



Re: [hackers] [sbase] ed: Don't use strlcpy() || Roberto E. Vargas Caballero

2017-01-10 Thread Hiltjo Posthuma
On Tue, Jan 10, 2017 at 08:56:46AM +0100, g...@suckless.org wrote:
> commit b95c8ed79e5d5322dd3c5c386c3acd62105ac116
> Author: Roberto E. Vargas Caballero 
> AuthorDate: Tue Jan 10 08:46:48 2017 +0100
> Commit: Roberto E. Vargas Caballero 
> CommitDate: Tue Jan 10 08:49:17 2017 +0100
> 
> ed: Don't use strlcpy()
> 
> All the buffers related to files have FILENAME_MAX size, so it is 
> impossible
> to have any buffer overrun.
> 
> diff --git a/ed.c b/ed.c
> index f579116..82fb784 100644
> --- a/ed.c
> +++ b/ed.c
> @@ -611,7 +611,7 @@ dowrite(const char *fname, int trunc)
>   curln = line2;
>   if (fclose(fp))
>   error("input/output error");
> - if (strlcpy(savfname, fname, sizeof(savfname)) >= sizeof(savfname))
> + if (strcpy(savfname, fname, sizeof(savfname)) >= sizeof(savfname))
>   error("file name too long");

I'm not sure if the strcpy check makes sense here. Is it intended?

To:
strcpy(savfname, fname, sizeof(savfname));

>   modflag = 0;
>   curln = line;
> @@ -743,8 +743,7 @@ getfname(char comm)
>   } else {
>   *bp = '\0';
>   if (savfname[0] == '\0' || comm == 'e' || comm == 'f')
> - if (strlcpy(savfname, fname, sizeof(savfname)) >= 
> sizeof(savfname))
> - error("file name too long");
> + strcpy(savfname, fname);
>   return fname;
>   }
>  
> 

-- 
Kind regards,
Hiltjo



[hackers] [sbase] ed: Don't use strlcpy() || Roberto E. Vargas Caballero

2017-01-09 Thread git
commit b95c8ed79e5d5322dd3c5c386c3acd62105ac116
Author: Roberto E. Vargas Caballero 
AuthorDate: Tue Jan 10 08:46:48 2017 +0100
Commit: Roberto E. Vargas Caballero 
CommitDate: Tue Jan 10 08:49:17 2017 +0100

ed: Don't use strlcpy()

All the buffers related to files have FILENAME_MAX size, so it is impossible
to have any buffer overrun.

diff --git a/ed.c b/ed.c
index f579116..82fb784 100644
--- a/ed.c
+++ b/ed.c
@@ -611,7 +611,7 @@ dowrite(const char *fname, int trunc)
curln = line2;
if (fclose(fp))
error("input/output error");
-   if (strlcpy(savfname, fname, sizeof(savfname)) >= sizeof(savfname))
+   if (strcpy(savfname, fname, sizeof(savfname)) >= sizeof(savfname))
error("file name too long");
modflag = 0;
curln = line;
@@ -743,8 +743,7 @@ getfname(char comm)
} else {
*bp = '\0';
if (savfname[0] == '\0' || comm == 'e' || comm == 'f')
-   if (strlcpy(savfname, fname, sizeof(savfname)) >= 
sizeof(savfname))
-   error("file name too long");
+   strcpy(savfname, fname);
return fname;
}