summaryrefslogtreecommitdiff
path: root/service_solahart_jakarta_selatan__082122541663/mig_strings.mdwn
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