Your message dated Mon, 21 Aug 2017 08:59:19 +0200
with message-id <[email protected]>
and subject line Bug#751409: libc6-dev: endian.h macros don't always return the
correct type
has caused the Debian Bug report #751409,
regarding libc6-dev: endian.h macros don't always return the correct type
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
751409: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751409
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libc6-dev
Version: 2.19-1
Severity: normal
Depending on the endian of the system, the macros le64toh(), be64toh(),
htole64(), htobe64(), etc. could not return a 64-bit type. This can lead to
issues ranging from compilation errors to runtime crashes.
Here is a simple example:
#include <endian.h>
#include <stdio.h>
int main(void)
{
printf("%u\n", (unsigned)sizeof(htobe64(1)));
return 0;
}
On a little endian system this will print 8 while on a big endian system it
will print 4. The reason is that on a big endian system the printf line expands
to:
printf("%u\n", (unsigned)sizeof((1)));
This can cause many different types of errors (e.g. when passing arguments to a
varargs function).
The simplest solution is to change the macros in endian.h to cast the result to
the expected type. For example change this:
#define htobe64(x) (x)
to this:
#define htobe64(x) (uint64_t)(x)
I'm going to create a patch for this.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: mips (mips64)
Kernel: Linux 3.2.0-4-5kc-malta
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6-dev depends on:
ii libc-dev-bin 2.19-1
ii libc6 2.19-1
ii linux-libc-dev 3.14.4-1
Versions of packages libc6-dev recommends:
ii gcc [c-compiler] 4:4.8.2-4
ii gcc-4.8 [c-compiler] 4.8.3-2
Versions of packages libc6-dev suggests:
pn glibc-doc <none>
ii manpages-dev 3.65-1
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 2.25-0experimental0
On 2014-06-12 15:23, Plamen Alexandrov wrote:
> Package: libc6-dev
> Version: 2.19-1
> Severity: normal
>
> Depending on the endian of the system, the macros le64toh(), be64toh(),
> htole64(), htobe64(), etc. could not return a 64-bit type. This can lead to
> issues ranging from compilation errors to runtime crashes.
>
> Here is a simple example:
>
> #include <endian.h>
> #include <stdio.h>
> int main(void)
> {
> printf("%u\n", (unsigned)sizeof(htobe64(1)));
> return 0;
> }
>
> On a little endian system this will print 8 while on a big endian system it
> will print 4. The reason is that on a big endian system the printf line
> expands to:
>
> printf("%u\n", (unsigned)sizeof((1)));
>
> This can cause many different types of errors (e.g. when passing arguments to
> a varargs function).
>
> The simplest solution is to change the macros in endian.h to cast the result
> to the expected type. For example change this:
> #define htobe64(x) (x)
> to this:
> #define htobe64(x) (uint64_t)(x)
>
> I'm going to create a patch for this.
This has now been fixed upstream in version 2.25, which has first been
packaged in Debian as version 2.25-0experimental0. I am therefore
closing the bug.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
[email protected] http://www.aurel32.net
--- End Message ---
