[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#751409: marked as done (libc6-dev: endian.h macros don't always return the correct type)

Your message dated Mon, 21 Aug 2017 08:59:19 +0200
with message-id <20170821065919.ncwmbj7x52qkw36f@aurel32.net>
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 owner@bugs.debian.org
immediately.)


-- 
751409: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751409
Debian Bug Tracking System
Contact owner@bugs.debian.org 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
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: