This is sources Bugzilla
Bugzilla Version 2.17.5
Bugzilla Bug 1499
  syslog.c:openlog_internal cuts _PATH_LOG Last modified: 2005-12-23 04:37:45
     Query page      Enter new bug
Bug#: 1499   Hardware:   Reporter: Andreas Köhler <andi5.py@gmx.net>
Host: Target: Build:
Product:     Add CC:
Component:   Version:   CC:
Remove selected CCs
Status: RESOLVED   Priority:  
Resolution: FIXED   Severity:  
Assigned To: Ulrich Drepper <drepper@redhat.com>   Target Milestone:  
Flags: Requestee:
  backport ()
  examined ()
  testsuite ()
Summary:
Keywords:

Attachment Description Type Created Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 1499 depends on: Show dependency tree
Show dependency graph
Bug 1499 blocks:

Additional Comments:


Leave as RESOLVED FIXED
Reopen bug
Mark bug as VERIFIED

View Bug Activity   |   Format For Printing


Description:   Last confirmed: 0000-00-00 00:00 Opened: 2005-10-18 22:23
Glibc 2.3.5 ( GCC 3.4.4, BinUtils 2.16.1, Linux 2.6.13.2 )  After changing misc/sys/syslog.h _PATH_LOG to something different, sysdeps/generic/syslog.c:openlog_internal starts cutting this path to 14 bytes while copying to a sockaddr, maybe because it thinks it knows the variable.  I do not know the correct solution to this, at least I did not find documentation that clearly states that this macro is fixed or has a maximal length. But I guess allocating enough memory for it should not destabilize glibc.  PS: If this is wontfix or similar, i would still like to see some patch for it :)

------- Additional Comment #1 From Andreas Köhler 2005-10-18 22:26 -------
I am sorry for reposting, but I did not plan it that way:

Glibc 2.3.5
( GCC 3.4.4, BinUtils 2.16.1, Linux 2.6.13.2 )

After changing misc/sys/syslog.h _PATH_LOG to something different,
sysdeps/generic/syslog.c:openlog_internal starts cutting this path
to 14 bytes while copying to a sockaddr, maybe because it thinks it
knows the variable.

I do not know the correct solution to this, at least I did not find
documentation that clearly states that this macro is fixed or has a
maximal length. But I guess allocating enough memory for it should
not destabilize glibc.

PS: If this is wontfix or similar, i would still like to see some
patch for it :)

------- Additional Comment #2 From Ulrich Drepper 2005-12-23 04:37 -------
I checked in a patch on the trunk.

     Query page      Enter new bug
Actions: New | Query | bug # | Reports | Requests   New Account | Log In