On Fri, Dec 25, 2015 at 11:47:19AM +0900, Masao Uebayashi wrote:
> On Tue, Dec 22, 2015 at 09:03:56PM +1000, Jonathan Matthew wrote:
> > On Tue, Dec 22, 2015 at 06:42:23PM +0900, Masao Uebayashi wrote:
> > > On Mon, Dec 21, 2015 at 03:53:09PM +0100, Mark Kettenis wrote:
> > > > > Date: Mon, 21 Dec
Hi Christian & Michael,
Michael McConville wrote on Thu, Dec 24, 2015 at 04:19:03PM -0500:
> Christian Heckendorf wrote:
>> A couple of somewhat recent changes in NetBSD's libedit permit
>> el_gets(3) to accept multibyte characters if the locale supports
>> it.
Ugh. The amount of indirection in
On Fri, Dec 25, 2015 at 11:47:19AM +0900, Masao Uebayashi wrote:
(snip)
> Without learning much about sensor part of IPMI, I think that both reading
> bits and "Get Sensor Thresholds Command" work. ...
I meant: both ... *should* work.
On Tue, Dec 22, 2015 at 09:03:56PM +1000, Jonathan Matthew wrote:
> On Tue, Dec 22, 2015 at 06:42:23PM +0900, Masao Uebayashi wrote:
> > On Mon, Dec 21, 2015 at 03:53:09PM +0100, Mark Kettenis wrote:
> > > > Date: Mon, 21 Dec 2015 22:47:19 +0900
> > > > From: Masao Uebayashi
> > > >
> > > > ipmi(
>> - activate stack protector
>
> Hm? Changing the exit to a return does this?
yes, stack protector only works if the function returns.
Fourth file, fourth broken file.
This is the worst bug found so far.
All i'm doing is grepping libc/stdio for "EILSEQ".
So far, every single instance i looked at was buggy.
I think we should cvs rm libc.
The code quality just isn't up to OpwnBSD standards.
When fprintf(fp, "...%ls...", ...) enco
Christian Heckendorf wrote:
> * Michael McConville [24.12.2015. @16:19:03 -0500]:
>
> > Christian Heckendorf wrote:
> > > A couple of somewhat recent changes in NetBSD's libedit permit
> > > el_gets(3) to accept multibyte characters if the locale supports
> > > it.
> > >
> > > A notable user of
* Michael McConville [24.12.2015. @16:19:03 -0500]:
> Christian Heckendorf wrote:
> > A couple of somewhat recent changes in NetBSD's libedit permit
> > el_gets(3) to accept multibyte characters if the locale supports
> > it.
> >
> > A notable user of this function is sftp(1) which will allow us
Third file, third bug.
SO FAR, EACH AND EVERY BLOODY PLACE I LOOKED AT WAS BROKEN.
When fputwc(3) encounters an encoding error, it neglects to set the
error indicator, just like fgetwc(3) did before i fixed it today.
Setting the error indicator is required by the manual and by the
standard.
Inste
Christian Heckendorf wrote:
> A couple of somewhat recent changes in NetBSD's libedit permit
> el_gets(3) to accept multibyte characters if the locale supports
> it.
>
> A notable user of this function is sftp(1) which will allow users to
> input multibyte characters, in filenames for example, onc
A couple of somewhat recent changes in NetBSD's libedit permit
el_gets(3) to accept multibyte characters if the locale supports
it.
A notable user of this function is sftp(1) which will allow users to
input multibyte characters, in filenames for example, once the diff
is applied.
--
Christian
I
Crap alert. Seriously. My impression is, whereever you look in
the wide character functions in our libc, it's broken. At least,
i looked at two files of twenty lines each and found a bug in each
of them. I don't believe in luck. I expect more cheap targets.
When errno happens to be EILSEQ upo
On Wed, Dec 23, 2015 at 9:27 AM, Ingo Schwarze wrote:
> i just noticed a bug in fgetwc(3) in our libc, the function used to
> implement getwc(3), getwchar(3), getws(3), getwln(3) and the wscanf(3)
> family of functions. In case of an encoding error, it does not set
> the error indicator, such tha
Michael McConville wrote:
> 1. realloc acts like malloc when ptr == NULL
> 2. no need to check for NULL before free
>
> ok?
I found the same pair in libc. ok?
Index: lib/libc/time/strftime.c
===
RCS file: /cvs/src/lib/libc/time/str
1. realloc acts like malloc when ptr == NULL
2. no need to check for NULL before free
ok?
? cscope.out
Index: skeleton.c
===
RCS file: /cvs/src/usr.bin/yacc/skeleton.c,v
retrieving revision 1.35
diff -u -p -r1.35 skeleton.c
--- skel
Theo de Raadt wrote:
> I don't know if I am alone in this -- I am getting a bit tired of
> changes which are can be summarized as: "fighting someone else's
> style".
>
> I do not really see the value in changes of this sort.
Agreed. I ordered the includes, but the void casts should just stay.
I'
>Theo de Raadt wrote:
>> I don't know if I am alone in this -- I am getting a bit tired of
>> changes which are can be summarized as: "fighting someone else's
>> style".
>>
>> I do not really see the value in changes of this sort.
>
>Agreed. I ordered the includes, but the void casts should just s
I don't know if I am alone in this -- I am getting a bit tired of
changes which are can be summarized as: "fighting someone else's style".
I do not really see the value in changes of this sort.
>frit...@alokat.org wrote:
>> Hi tech@,
>>
>> here are some basename(1) tweaks:
>> - remove (void) cas
frit...@alokat.org wrote:
> Hi tech@,
>
> here are some basename(1) tweaks:
> - remove (void) cast for puts(3) and fprintf(3)
We typically leave these. I agree that they're usually pointless visual
distractions in 2015 because there are a set of functions (mostly
blocking IO functions to stdout a
Hi tech@,
here are some basename(1) tweaks:
- remove (void) cast for puts(3) and fprintf(3)
- activate stack protector
- put includes in correct order
--F.
Index: basename.c
===
RCS file: /cvs/src/usr.bin/basename/basename.c,v
retr
Martin Natano wrote:
> Hi,
>
> the diff reads fine to me, except for following nit-picks: It would be
> nice if the hashfree() function would check for negative/zero element
> counts, like hashinit() does. Also, new functionality should be
> documented in the manual.
>
> Please find below a regen
Dear tech@ readers,
On 11/21/15 13:20, Alessandro DE LAURENZIS wrote:
> Dear tech@,
>
> This is an attempt to solve a problem I previously reported [1] to
> misc@ (without receiving any feedback, so far).
[...]
> [1] http://marc.info/?l=openbsd-misc&m=144800414402238&w=2
>
my second attempt...
frit...@alokat.org(frit...@alokat.org) on 2015.12.24 14:45:51 +0100:
> On Thu, Dec 24, 2015 at 02:19:36PM +0100, Theo Buehler wrote:
> > On Thu, Dec 24, 2015 at 01:52:56PM +0100, frit...@alokat.org wrote:
> > > Hi tech@,
> > >
> > > here are some tweaks about uname(1):
> > >
> > > - change the pa
Hi,
the diff reads fine to me, except for following nit-picks: It would be
nice if the hashfree() function would check for negative/zero element
counts, like hashinit() does. Also, new functionality should be
documented in the manual.
Please find below a regenerated diff including both changes.
On Thu, Dec 24, 2015 at 02:19:36PM +0100, Theo Buehler wrote:
> On Thu, Dec 24, 2015 at 01:52:56PM +0100, frit...@alokat.org wrote:
> > Hi tech@,
> >
> > here are some tweaks about uname(1):
> >
> > - change the parameter order to the same order as in the manpage
> > - change err(1, NULL) to errx
On Thu, Dec 24, 2015 at 01:52:56PM +0100, frit...@alokat.org wrote:
> Hi tech@,
>
> here are some tweaks about uname(1):
>
> - change the parameter order to the same order as in the manpage
> - change err(1, NULL) to errx(1, "uname")
Why? This doesn't make sense to me. Like this you'll suppres
Hi tech@,
here are some tweaks about uname(1):
- change the parameter order to the same order as in the manpage
- change err(1, NULL) to errx(1, "uname")
- change statements like: if (condition) statement
if (condition)
statement
- activate the stack protector
--F.
Index: uname.c
Ingo Schwarze writes:
> Hi,
>
> i just noticed a bug in fgetwc(3) in our libc, the function used to
> implement getwc(3), getwchar(3), getws(3), getwln(3) and the wscanf(3)
> family of functions. In case of an encoding error, it does not set
> the error indicator, such that a program correctly c
Ralf Horstmann writes:
> Hi,
>
> xdg-open uses "xdg-mime query filetype" to find out the mime type of a given
> file. Depending on the desktop environment, xdg-mime uses different backends.
> In my case (i3 wm) it falls back to the generic code path, which uses
>
> file --brief --dereference
This diff adds transpose-words to mg. It behaves slightly differently
from emacs when it comes to muliple iterations. Take this text for
example:
abc def ghi
jkl mno pqr
If the cursor is on the 'd', then you do C-u 3 M-t, in emacs the
result will be:
abc ghi
jkl mno def pqr
The attached diff g
30 matches
Mail list logo
