> This feels not good.
> strncpy->strlcpy has repercussions like how strlcpy doesn't zero out the
> remaining length and thus leaks uninitialized data.
>
> There has to be a reasonable way to handle these warnings instead of
> rototilling which str*cpy function is used.
Please read the code befo
On Sun, May 31, 2020 at 07:24:24PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sun May 31 23:24:24 UTC 2020
>
> Modified Files:
> src/lib/libedit: terminal.c tty.c
>
> Log Message:
> use strlcpy() instead of strncpy() for gcc happiness
>
...
In article <20170629025440.3550df...@cvs.netbsd.org>,
Robert Elz wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kre
>Date: Thu Jun 29 02:54:40 UTC 2017
>
>Modified Files:
> src/lib/libedit: literal.c
>
>Log Message:
>Fix an obvious, but almost invisible typo (avoid some c
On Jun 18, 7:49pm, m...@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: CVS commit: src/lib/libedit/TEST
|
| On Jun 18, 2014, at 1:12 PM, Christos Zoulas wrote:
|
| > cast gotsig because it is long on some systems.
|
| Why cast to int instead of long?
Because the only values we set
On Jun 18, 2014, at 1:12 PM, Christos Zoulas wrote:
> cast gotsig because it is long on some systems.
Why cast to int instead of long?
In article <537a6540.1070...@gmx.de>,
Christoph Egger wrote:
>
>private? I think you mean static, right?
It does if compiled that way. Helps to read the rest of the file instead
of just diffs :-)
christos
Am 19.05.14 21:54, schrieb Christos Zoulas:
> Module Name: src
> Committed By: christos
> Date: Mon May 19 19:54:12 UTC 2014
>
> Modified Files:
> src/lib/libedit: tty.c tty.h
>
> Log Message:
> more tty modes refactoring, no functional change intended.
>
>
> To generate a diff o
On Wed, Aug 28, 2013 at 06:09:21PM +, Christos Zoulas wrote:
> > > Log Message:
> > > get rid of PATH_MAX.
> >
> >...by leaking memory?
>
> How so? It probably uses less memory than before, but not on the bss
> but on the data segment.
Sorry, misread.
--
David A. Holland
dholl...@net
In article <20130828170952.ga22...@netbsd.org>,
David Holland wrote:
>On Wed, Aug 28, 2013 at 04:05:21AM -0400, Christos Zoulas wrote:
> > Modified Files:
> > src/lib/libedit: readline.c
> >
> > Log Message:
> > get rid of PATH_MAX.
>
>...by leaking memory?
How so? It probably uses less mem
On Wed, Aug 28, 2013 at 04:05:21AM -0400, Christos Zoulas wrote:
> Modified Files:
> src/lib/libedit: readline.c
>
> Log Message:
> get rid of PATH_MAX.
...by leaking memory?
--
David A. Holland
dholl...@netbsd.org
Can we please stop abusing the notation of "GCC is available" to mean
"GCC is used"? If you want a GCC-specific warning flag, at least put it
into CWARNFLAGS.gcc. I'm actually in favour of dropping this
unconditionally -- GCC 4.1 is just behaving way too lax for this option
to make sense.
Joerg
O
On Sun, Jul 31, 2011 at 00:50:03 +, Christos Zoulas wrote:
> In article <20110730205523.gb3...@britannica.bec.de>,
> Joerg Sonnenberger wrote:
> >Just cast the parameter to void?
>
> Do you prefer this than __unused?
I too would prefer something in the body of the function(wrapped in a
mac
In article <20110730205523.gb3...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>Just cast the parameter to void?
Do you prefer this than __unused?
christos
In article <20110730064751.ga19...@apb-laptoy.apb.alt.za>,
Alan Barrett wrote:
>On Fri, 29 Jul 2011, Christos Zoulas wrote:
>>Log Message:
>>add -Wunused-parameter
>>Is that the right way? Perhaps WARNS=5?
>
>Or add -Wunused-parameter to WARNS=4.
>
>WARNS levels should be organised by the ease of
Just cast the parameter to void?
On Fri, Jul 29, 2011 at 04:58:07PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Fri Jul 29 20:58:07 UTC 2011
>
> Modified Files:
> src/lib/libedit: common.c filecomplete.c history.c readline.c vi.c
>
> Log Messa
On Fri, 29 Jul 2011, Christos Zoulas wrote:
Log Message:
add -Wunused-parameter
Is that the right way? Perhaps WARNS=5?
Or add -Wunused-parameter to WARNS=4.
WARNS levels should be organised by the ease of avoiding or fixing the
warnings; there's no need to add a new level for each warning.
-
In article <20100419075526.ga1...@apb-laptoy.apb.alt.za>,
Alan Barrett wrote:
>On Sun, 18 Apr 2010, Christos Zoulas wrote:
>> Modified Files:
>> src/lib/libedit: makelist
>>
>> Log Message:
>> shame on solaris that is the last OS not supporting $()
>
>build.sh tries to set HOST_SH=/usr/xpg4
On Sun, 18 Apr 2010, Christos Zoulas wrote:
> Modified Files:
> src/lib/libedit: makelist
>
> Log Message:
> shame on solaris that is the last OS not supporting $()
build.sh tries to set HOST_SH=/usr/xpg4/bin/sh on Solaris, and that
shell does support $(...). Also, we make free use of $(..
On Mar 7, 7:46am, takehiko.noz...@gmail.com (Takehiko NOZAKI) wrote:
-- Subject: Re: CVS commit: src/lib/libedit
| oh, i see. i don't recognize NARROW_READ flag.
| source/binary compatibility are still **kept**,
| i withdrawn previous mail, sorry.
|
|
| BTW, this hack is not goo
ause where we convert multibyte -> wide-character is
# EL_BUILTIN_GETCFN(=read_char) itself.
very truly yours.
--
Takehiko NOZAKI
2010/3/7 Christos Zoulas :
> On Mar 7, 5:24am, takehiko.noz...@gmail.com (Takehiko NOZAKI) wrote:
> -- Subject: Re: CVS commit: src/lib/libedit
>
>
On Mar 7, 5:24am, takehiko.noz...@gmail.com (Takehiko NOZAKI) wrote:
-- Subject: Re: CVS commit: src/lib/libedit
| -typedef int (*el_rfunc_t)(EditLine *, char *);
| +typedef int (*el_rfunc_t)(EditLine *, Char *);
|
| typedef struct el_read_t {
| el_rfunc_t read_char
hi, all.
i found one more big problem.
we had lost source/binary level backward compatibility, sigh.
el_set(3) defines EL_GETCFN flag, and some application(such as Asterisk) use it:
el_set()
Set editline parameters. op determines which parameter to set, and
each opera
On Jan 14, 2:57am, y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
-- Subject: Re: CVS commit: src/lib/libedit
| > Once we verify that it works on non utf-8, sure.
|
| what do you mean by "verify"?
Now we do know that it does not work on non-utf-8 locales, because it
has u
> On Jan 13, 8:21am, y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> -- Subject: Re: CVS commit: src/lib/libedit
>
> | hi,
> |
> | can you please don't hardcode utf-8?
> |
> | YAMAMOTO Takashi
>
> Once we verify that it works on non utf-8, sure.
what
hi, all.
i found following problems this patch:
1. don't write UTF-8 locale dependent ``cheat'' code in locale
independent libedit,
such as enc_width(), utf8_islead() and so on, completely meaningless.
our locale implementation is "CodeSet Independ" policy, wchar_t != UCS4.
please read itojun@'s
On Jan 13, 8:21am, y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
-- Subject: Re: CVS commit: src/lib/libedit
| hi,
|
| can you please don't hardcode utf-8?
|
| YAMAMOTO Takashi
Once we verify that it works on non utf-8, sure.
christos
hi,
can you please don't hardcode utf-8?
YAMAMOTO Takashi
> Module Name: src
> Committed By: christos
> Date: Wed Dec 30 22:37:40 UTC 2009
>
> Modified Files:
> src/lib/libedit: Makefile chared.c chared.h common.c el.c el.h emacs.c
> filecomplete.c filecomplete.h hist.c
In article <335.1252361...@splode.eterna.com.au>,
matthew green wrote:
>
> Module Name:src
> Committed By: christos
> Date: Mon Sep 7 21:24:34 UTC 2009
>
> Modified Files:
> src/lib/libedit: histedit.h history.c readline.c
> src/lib/libedit/read
Module Name: src
Committed By:christos
Date:Mon Sep 7 21:24:34 UTC 2009
Modified Files:
src/lib/libedit: histedit.h history.c readline.c
src/lib/libedit/readline: readline.h
Log Message:
apply apple patches from:
http://opensour
Modified Files:
src/lib/libedit: sys.h term.c
src/lib/libedit/readline: readline.h
Log Message:
use __sun || sun instead of _SunOS, from Jess Thrysoee
can we not invade the users name space? "sun" doesn't appear alone
anymore anywhere we care right?
.mrg.
30 matches
Mail list logo
