Your message dated Thu, 9 Jan 2025 21:42:03 +0100
with message-id
and subject line Re: Bug#666454: sizeof(struct sigevent) is smaller than the
kernel definition
has caused the Debian Bug report #666454,
regarding sizeof(struct sigevent) is smaller than the kernel definition
to be marked as done
https://sourceware.org/bugzilla/show_bug.cgi?id=3973
Florian Weimer changed:
What|Removed |Added
CC||fweimer at redhat dot com
Co
Your message dated Sun, 20 Aug 2017 17:26:42 +
with message-id
and subject line Bug#827703: fixed in glibc 2.25-0experimental1
has caused the Debian Bug report #827703,
regarding libc6: misaligned accesses in res_query.c to fields in HEADER struct
to be marked as done.
This means that you
-unaligned.diff: new patch to fix
misaligned accesses in res_query.c to fields in HEADER struct (closes: #827703).
---
debian/changelog | 5 +
debian/patches/series | 1 +
2 files changed, 6 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 73ad7ab..7f08a75 100644
--- a/debian
Package: libc6-dev
Version: 2.24-10
Hello,
I'm investigating cockpit's build failure on x32 [1]. It builds with
-Werror=format=2 to detect format string type errors, and compiling
| struct stat *buf)
| [...]
| return g_strdup_printf (&quo
New patch is here:
https://sourceware.org/ml/libc-alpha/2016-06/msg01020.html
Dave
--
John David Anglin dave.ang...@bell.net
Package: libc6
Version: 2.22-11+b3
Severity: normal
Dear Maintainer,
We see various misaligned accesses reported on the console and in the syslog
running apt-get on hppa:
http(13559): unaligned access to 0xfa703d49 at ip=0xf9f0a9bb
handle_unaligned: 37 callbacks suppressed
http(1
Your message dated Sun, 13 Mar 2016 23:07:10 +0100
with message-id <20160313220710.ga20...@aurel32.net>
and subject line Bug#545888: libc0.3-dev: struct ether_addr defined twice
has caused the Debian Bug report #545888,
regarding libc0.3-dev: struct ether_addr defined twice
to be marked a
Your message dated Sun, 29 Apr 2012 17:19:05 +
with message-id
and subject line Bug#669424: fixed in eglibc 2.13-31
has caused the Debian Bug report #669424,
regarding missing struct loadavg
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not
. buffer overflow).
Unfortunately size of this struct can't be increased without breaking ABI.
-- System Information:
Debian Release: 6.0.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kF
On Sat, Dec 17, 2011 at 7:54 PM, peter green wrote:
>> Your patch to fix ucontext namespace pollution looks good, please post
>> that to libc-ports for review
>
> should I send it immidiately or should I wait until I have test results to
> give them?
Wait until the test results are complete and y
ISO C99 says that WCHAR_MAX must be a constant expression and the
above definition is such an expression. Technically the program needs
fixing (see below though for the "standards matter but so do users"),
there is nothing wrong with a type cast and a constant value e.g.
signed -1 converted to u
On Sat, Dec 17, 2011 at 7:57 AM, peter green wrote:
>> mind also looking at WCHAR_MIN/MAX undefined for arm?
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598937
>
> They most certainly are defined. The trouble is that WCHAR_MAX is defined
> in a strange way.
>
> #define __WCHAR_MAX ( (w
_R10
+ REG_R11 = 11,
+#define REG_R11 REG_R11
+ REG_R12 = 12,
+#define REG_R12 REG_R12
+ REG_R13 = 13,
+#define REG_R13 REG_R13
+ REG_R14 = 14,
+#define REG_R14 REG_R14
+ REG_R15 = 15
+#define REG_R15 REG_R15
};
+struct _libc_fpstate
+{
+ struct
+ {
+unsigned int sign1:1;
+un
On 17 December 2011 09:17, peter green
wrote:
> While we are talking about modifying sys/ucontext.h David Given
> raised another issue with that header (for those reading on the linaro list
> his
> post can be found at
> http://lists.debian.org/debian-arm/2011/12/msg00048.html)
> David Given>This
Ulrich Weigand>Now, glibc also provides a file that defines
Ulrich Weigand>layouts of register sets for use with signal handlers as well
Ulrich Weigand>as the makecontext/setcontext/getcontext family of routines.
Ulrich Weigand>
Ulrich Weigand>Usually, those layouts tend to be in fact identical t
On Thu, Dec 15, 2011 at 1:52 PM, peter green wrote:
> From my tests it seems that in both squeeze and sid __USE_XOPEN2K8 gets
> defined by default
> (in ) but __USE_XOPEN does not.
> so this change to the ifdef changed it from "default no" to "default yes"
>
> Reverting the change the ifdef would
>As a first step why don't you try breaking the header include chain in
glibc, and rebuild gdb to ensure everything works?
It looks like there are two places the chain could reasonablly be
broken. sys/ucontext.h could stop including sys/procfs.h
(this would match amd64) or signal.h could stop inc
Wookey wrote:
> We can
> 1) Change every app in the world that defines a 'struct user'
> 2) Stop these headers getting brought in when not actually needed
> (it's a relatively recent change that brings it in)
> 3) Change the name in glibc/GDB to something less li
on what exactly is involved in doing that and whether we
> can agree on how things should be fixed.
>
> As I said i'm not convinced that gdb needs to be changed.
As a first step why don't you try breaking the header include chain in
glibc, and rebuild gdb to ensure everything
hort:
A C app that defines a struct 'user' and uses wait.h or signal.h will
find a clash with the system struct of the same name, which should
only be needed for GDB (when built on/for arm).
On other arches this is not pulled in by default so the problem doesn't arise.
We can
1
Carlos O'Donell wrote:
As an upstream glibc maintainer I would be happy to see this fixed in
glibc and gdb, but nobody has stepped up to fix it.
Ok.
The `struct user` is used by the gdbserver code that uses ptrace
(PTRACE_PEEKUSR/POKEUSR) to peek/poke at the inferior and read out
s
see this fixed in
glibc and gdb, but nobody has stepped up to fix it.
The `struct user` is used by the gdbserver code that uses ptrace
(PTRACE_PEEKUSR/POKEUSR) to peek/poke at the inferior and read out
stored register values from the USER area. The userspace definition of
`struct user` is equi
recently i've been seeing some packages FTBFS on armhf with definition
clashes of struct
user. Test building packages the package on armel has invariblly shown
the issue
happening there as well despite the same version of the source package
having built there
successfully in the past. I&#x
Processing commands for cont...@bugs.debian.org:
> reassign 646918 kfreebsd-kernel-headers
Bug #646918 [libc0.1-dev] /usr/include/sys/nlist_aout.h:51: error: redefinition
of âstruct nlistâ
Bug reassigned from package 'libc0.1-dev' to 'kfreebsd-kernel-headers'.
Bug No
> #include
>
> main ()
> {
> struct nlist nl;
> nl.n_un.n_strx = 0;
> }
>
> It appears there are conflicting definitions of "struct nlist", one of them in
> libc-dev and the other in kfreebsd-kernel-headers:
>
> $ gcc /tmp/test.c -o /tmp/test
> In file
Package: libc0.1-dev
Version: 2.11.2-10
Severity: normal
The following code compiles on FreeBSD but not on Debian GNU/kFreeBSD:
#include
#include
main ()
{
struct nlist nl;
nl.n_un.n_strx = 0;
}
It appears there are conflicting definitions of "struct nlist", one of them in
li
ds,
Robert Paciorek
http://www.opcode.eu.org/bercik
-- Step to reproduce:
following code:
#include
#include
main() {
time_t t = 0;
struct tm tt;
char buf[40];
puts("using strftime and %s from gmtime_r time in non UTC timezone");
Your message dated Mon, 04 Jul 2011 21:35:04 +
with message-id
and subject line Bug#324051: fixed in eglibc 2.13-10
has caused the Debian Bug report #324051,
regarding bad struct statvfs declaration on Alpha when _FILE_OFFSET_BITBITS is
defined
to be marked as done.
This means that you
:
/usr/include/bits/pthreadtypes.h:99: warning: unnamed struct/union that defines
no instances
I know gcc-2.95 is totally outdated, but it is useful for regression testing
of old version of software that were only tested with it, this warning cause
lots of noise, and there is no way to disable it
On Sun, Dec 27, 2009 at 01:35:43AM +0100, Juliusz Chroboczek wrote:
> > There is no risk of breakage in optimised code with -O2 or more.
>
> For my education -- could you please explain why? (No need to quote the
> C99 standard, just give me the intuition.)
>
It is a false positive due to the f
> There is no risk of breakage in optimised code with -O2 or more.
For my education -- could you please explain why? (No need to quote the
C99 standard, just give me the intuition.)
Juliusz
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.
severity 561691 wishlist
tag 561691 + wontfix
thanks
On Sat, Dec 19, 2009 at 06:03:48PM +0100, Juliusz Chroboczek wrote:
> Package: libc6-dev
> Version: 2.10.2-2
>
> Type punning between pointers to struct sockaddr, struct sockaddr_storage
> and sockaddr_in(6) is explicitly
Processing commands for cont...@bugs.debian.org:
> severity 561691 wishlist
Bug #561691 [libc6-dev] Please declare struct sockaddr and sockaddr_storage as
may_alias
Ignoring request to change severity of Bug 561691 to the same value.
> tag 561691 + wontfix
Bug #561691 [libc6-dev] Please d
Package: libc6-dev
Version: 2.10.2-2
Type punning between pointers to struct sockaddr, struct sockaddr_storage
and sockaddr_in(6) is explicitly required by the sockets interface. For
example, RFC 3493 Section 3.8 gives the following example:
if (bind(s, (struct sockaddr *) &sin6, si
Subject: libc0.3-dev: struct ether_addr defined twice
Package: libc0.3-dev
Version: 2.9-25
Severity: normal
On Hurd (tested on strauss.debian.net) both /usr/include/net/ethernet.h
and /usr/include/netinet/if_ether.h define a struct ether_addr:
/usr/include/net/ethernet.h:
struct ether_addr
system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: libc6-dev
Version: 2.7-3
Severity: normal
According to LSB 3.1
http://www.linux-foundation.org/spec/refspecs/LSB_3.1.0/LSB-AMD64/LSB-AMD64.html#AEN4388
defines struct _fpstate as follows:
struct _fpstate {
ui
Package: libc6-dev
Version: 2.7-3
Severity: normal
According to LSB 3.1
http://www.linux-foundation.org/spec/refspecs/LSB_3.1.0/LSB-AMD64/LSB-AMD64.html#AEN4388
defines struct _fpstate as follows:
struct _fpstate {
uint16_t cwd;
uint16_t swd;
uint16_t ftw;
uint16_t fop
ibc/sysdeps/mach/hurd/xstatconv.c,v
retrieving revision 1.4
diff -u -p -r1.4 xstatconv.c
--- sysdeps/mach/hurd/xstatconv.c 11 Jun 2002 23:03:14 - 1.4
+++ sysdeps/mach/hurd/xstatconv.c 13 Jun 2006 13:57:55 -
@@ -42,12 +42,21 @@ xstat64_conv (struct stat *buf, const st
es.org 2006-09-19 13:00:49.0 +
+++ futimes.c 2006-09-19 13:05:13.0 +
@@ -28,20 +28,28 @@
int
__futimes (int fd, const struct timeval tvp[2])
{
- struct timeval timevals[2];
error_t err;
-
+
if (tvp == NULL)
{
+ volatile struct timeval timevals[2];
13:05:13.0 +
@@ -28,20 +28,28 @@
int
__futimes (int fd, const struct timeval tvp[2])
{
- struct timeval timevals[2];
error_t err;
-
+
if (tvp == NULL)
{
+ volatile struct timeval timevals[2];
/* Setting the number of microseconds to `-1' tells the
Processing commands for [EMAIL PROTECTED]:
> reassign 314435 manpages-dev
Bug#314435: libc6-dev: struct timespec and nanosleep() not available with
-std=c99
Bug reassigned from package `libc6-dev' to `manpages-dev'.
> thanks
Stopping processing here.
Please contact me if you
Hello Masanori,
On Sun, Jul 24, 2005 at 05:29:47PM +0900, GOTO Masanori wrote:
> > Should Linux man page be updated to mention _POSIX_C_SOURCE?
>
> I also don't know it should be described to linux man pages - if you
> think so, please reassign it to manpages-dev. However linux manpages
> is not
I'm able to compile the file without problems. However, neither
> SUSv3, nor Linux man page say anything about it. That is why I used to
> think that struct timespec and nanosleep MUST be available after a bare
> #include . Does POSIX specify whether the availability can be
> controll
p 2004 21:04:28 +0200 (CEST)
From: Jochen Friedrich <[EMAIL PROTECTED]>
X-X-Sender: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: /usr/include/linux/llc.h: old struct sockaddr_llc
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned:
ers
> that the C standard does not explicitly declare as defined by the
> standard, reserved for future versions of the standard, or reserved to
> the implementation. "struct timespec" and "nanosleep" are not such
> identifiers.
Indeed. I've overseen that time.h is a
On Thu, Jun 16, 2005 at 12:10:44PM +0200, Baurzhan Ismagulov wrote:
> struct timespec and nanosleep are POSIX, and should be defined in time.h
> according to SUSv3 (see, e.g.,
> http://www.opengroup.org/onlinepubs/007908799/xsh/nanosleep.html). I
> don't see why strict C99 complia
to, 2005-06-16 kello 12:10 +0200, Baurzhan Ismagulov kirjoitti:
> On Thu, Jun 16, 2005 at 12:47:13PM +0300, Lars Wirzenius wrote:
> > The -std=c99 option means that you want strict compliance to the 1999
> > version of the C standard. That standard does not define struct timespec
&
Hello Lars,
On Thu, Jun 16, 2005 at 12:47:13PM +0300, Lars Wirzenius wrote:
> The -std=c99 option means that you want strict compliance to the 1999
> version of the C standard. That standard does not define struct timespec
> or nanosleep in or anywhere else. Thus, there is no bug
to, 2005-06-16 kello 10:47 +0200, Baurzhan Ismagulov kirjoitti:
> #include
>
> int main(void)
> {
> struct timespec a;
> nanosleep(&a, &a);
> return 0;
> }
>
> Compilation with "gcc -Wall -g -std=c99" produces the following erro
Package: libc6-dev
Version: 2.3.2.ds1-21
Severity: normal
Hello,
consider the following example:
#include
int main(void)
{
struct timespec a;
nanosleep(&a, &a);
return 0;
}
Compilation with "gcc -Wall -g -std=c99" produces the following errors:
by ldl.fc.hp.com (Postfix) with ESMTP id 152061341EB;
Fri, 28 Jan 2005 11:12:36 -0700 (MST)
Subject: NPTL vs. LinuxThread sizeof(struct pthread) conflict causes memory
corruption
From: dann frazier <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [E
ff1f
which happened to hold the function descriptors for shared library linkage stubs
("jump slots"). Of relevance was that the thread-pointer (r13) had the value:
0x22db0500
The corruption was caused by any NPTL routine trying to access the
thread-descriptor, since NPTL use
Hi all,
I have a struct:
struct input_handle {
void *private;
int open; char *name;
struct input_dev *dev; struct
input_handler *handler;
struct list_head d_node; struct
list_head h_node;};
The problem is that I am wondering what d_node and
h_node represent. I think that
tags 271355 fixed-upstream
thanks
At Sun, 12 Sep 2004 21:04:28 +0200 (CEST),
Jochen Friedrich wrote:
> /usr/include/linux/llc.h contains rather old definitions of struct
> sockaddr_llc which have a different size than current 2.6 kernels.
>
> /usr/include/linux/llc.h contains:
Processing commands for [EMAIL PROTECTED]:
> tags 271355 fixed-upstream
Bug#271355: /usr/include/linux/llc.h: old struct sockaddr_llc
There were no tags set.
Tags added: fixed-upstream
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-17
Severity: minor
*** Please type your report below this line ***
/usr/include/linux/llc.h contains rather old definitions of struct
sockaddr_llc which have a different size than current 2.6 kernels.
/usr/include/linux/llc.h contains
- Forwarded message from James Troup <[EMAIL PROTECTED]> -
Subject: Bug#155100: glibc-doc: misleading definition of struct timeval from
Reply-To: James Troup <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Resent-From: James Troup <[EMAIL PROTECTED]>
Original-Sender: J
- Forwarded message from James Troup <[EMAIL PROTECTED]> -
Subject: Bug#155100: glibc-doc: misleading definition of struct timeval from
Reply-To: James Troup <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Resent-From: James Troup <[EMAIL PROTECTED]>
Original-Sender: J
59 matches
Mail list logo
