blob: 3693fcc212e2006c0319abca9d619381089f9c25 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
[[!meta copyright="Copyright © 2014 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
[[!tag open_issue_mig]]
[[!toc]]
# IRC, freenode, #hurd, 2014-02-21
<teythoon> grml... migs support for variable-length c strings is broken :(
<braunr> completely ..
<teythoon> no one told me :p
<braunr> noone dares
<teythoon> to tell me ?
<braunr> or anyone else ;p
<teythoon> ^^
<teythoon> root@debian:~# pkill mtab
<teythoon> task /hurd/procfs(19) �O� deallocating an invalid port 1049744,
most probably a bug.
<braunr> :)
<teythoon> it's still an improvement >,<
<teythoon> uh the joys...
<teythoon> gnu machs mig_strncpy behaves differently from glibcs
<teythoon> the mach version always 0-terminates the target string, the libc
variant does not
<teythoon> which one should i "fix" ?
<braunr> strncpy should behave like strncpy
<teythoon> not according to the documentation in gnumach...
<braunr> people who know it expect it not to always null terminate
<braunr> you can either fix mig_strncpy, or call it mig_strlcpy
|
