[Bug libc/16458] New: endian.h macros return integers of wrong type

[Bug libc/16458] New: endian.h macros return integers of wrong type

[jaak at ristioja dot ee]

https://sourceware.org/bugzilla/show_bug.cgi?id=16458

            Bug ID: 16458
           Summary: endian.h macros return integers of wrong type
           Product: glibc
           Version: 2.17
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: jaak at ristioja dot ee
                CC: drepper.fsp at gmail dot com

#define _BSD_SOURCE
#include <endian.h>
#include <stdint.h>

int main() {
  const long int i = 42;
  const uint64_t b = htole64(i);
  return (int) b;
}

$ gcc -Wsign-conversion test.c -o test
test.c: In function 'main':
test.c:7:3: warning: conversion to 'uint64_t' from 'long int' may change the
sign of the result [-Wsign-conversion]

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16458] endian.h macros return integers of wrong type

[neleai at seznam dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=16458

Ondrej Bilka <neleai at seznam dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |neleai at seznam dot cz
         Resolution|---                         |INVALID

--- Comment #1 from Ondrej Bilka <neleai at seznam dot cz> ---
This is documented behaviour. Manpage has following prototype:

SYNOPSIS
       #define _BSD_SOURCE           /* See feature_test_macros(7) */
       #include <endian.h>

       uint16_t htobe16(uint16_t host_16bits);
       uint16_t htole16(uint16_t host_16bits);
       uint16_t be16toh(uint16_t big_endian_16bits);
       uint16_t le16toh(uint16_t little_endian_16bits);

       uint32_t htobe32(uint32_t host_32bits);
       uint32_t htole32(uint32_t host_32bits);
       uint32_t be32toh(uint32_t big_endian_32bits);
       uint32_t le32toh(uint32_t little_endian_32bits);

       uint64_t htobe64(uint64_t host_64bits);
       uint64_t htole64(uint64_t host_64bits);
       uint64_t be64toh(uint64_t big_endian_64bits);
       uint64_t le64toh(uint64_t little_endian_64bits);

So you need to use uint64_t as type of i.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16458] endian.h macros return integers of wrong type

[jaak at ristioja dot ee]

https://sourceware.org/bugzilla/show_bug.cgi?id=16458

Jaak Ristioja <jaak at ristioja dot ee> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #2 from Jaak Ristioja <jaak at ristioja dot ee> ---
The manpage also explicitly says these are functions, not macros. And if these
were functions, they would in fact return values of the correct type,
regardless of the argument and parameter type, which is what the developer
expects in C. The only constraint being that "each argument shall have a type
such that its value may be assigned to an object with the unqualified version
of the type of its corresponding parameter" (i.e. ISO/IEC 9899:1999 6.5.2.2
Function calls).

If you insist these being macros, at least the documentation should be fixed
accordingly. Reopening.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16458] endian.h macros return integers of wrong type

[neleai at seznam dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=16458

Ondrej Bilka <neleai at seznam dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Ondrej Bilka <neleai at seznam dot cz> ---
> The manpage also explicitly says these are functions, not macros. And if these 
> were functions, they would in fact return values of the correct type, 
> regardless of the argument and parameter type, which is what the developer 
> expects in C. The only constraint being that "each argument shall have a type 
> such that its value may be assigned to an object with the unqualified version 
> of the type of its corresponding parameter" (i.e. ISO/IEC 9899:1999 6.5.2.2 
> Function calls

You are wrong here, A example that you supplied is invalid and you get same
warning with ordinary functions. Closing.

#include <stdint.h>

uint64_t foo(uint64_t bar)
{
  return bar;
}

int main() {
  const long int i = 42;
  const uint64_t b = foo(i);
  return (int) b;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16458] endian.h macros return integers of wrong type

[jaak at ristioja dot ee]

https://sourceware.org/bugzilla/show_bug.cgi?id=16458

Jaak Ristioja <jaak at ristioja dot ee> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #4 from Jaak Ristioja <jaak at ristioja dot ee> ---
Indeed. But I should also get a warning from this:

  #define _BSD_SOURCE
  #include <endian.h>  
  int main() {
    const long int i = 42;
    const long int b = htole64(i);
    return (int) b;
  }

Which I don't:

$ gcc -Wall -Wextra -Wsign-conversion -Wconversion
-Wimplicit-function-declaration test5.c -c

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16458] endian.h macros return integers of wrong type

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=16458

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 16 Jan 2014, jaak at ristioja dot ee wrote:

> If you insist these being macros, at least the documentation should be fixed
> accordingly. Reopening.

"The documentation" for glibc is the Texinfo manual; manpages are an 
independent project not covered by this tracker or the glibc maintainers.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16458] endian.h macros return integers of wrong type

[jaak at ristioja dot ee]

https://sourceware.org/bugzilla/show_bug.cgi?id=16458

--- Comment #6 from Jaak Ristioja <jaak at ristioja dot ee> ---
(In reply to joseph@codesourcery.com from comment #5)
> On Thu, 16 Jan 2014, jaak at ristioja dot ee wrote:
> 
> > If you insist these being macros, at least the documentation should be fixed
> > accordingly. Reopening.
> 
> "The documentation" for glibc is the Texinfo manual; manpages are an 
> independent project not covered by this tracker or the glibc maintainers.

It appears that these interfaces are undocumented in the Texinfo manual.

Why not just add simple casts to these macros? For example, instead of

  #   define htobe64(x) __bswap_64 (x)
  #   define htole64(x) (x)

use

  #   define htobe64(x) __bswap_64 ((uint64_t)(x))
  #   define htole64(x) ((uint64_t)(x))

PS: At first sight the htonl, htons, ntohl and ntohs macros in <netinet/in.h>
also appear to require similar casts.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16458] endian.h and netinet/in.h byte order macros return unsigned integers of wrong type

[jaak at ristioja dot ee]

https://sourceware.org/bugzilla/show_bug.cgi?id=16458

Jaak Ristioja <jaak at ristioja dot ee> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|endian.h macros return      |endian.h and netinet/in.h
                   |integers of wrong type      |byte order macros return
                   |                            |unsigned integers of wrong
                   |                            |type

--- Comment #7 from Jaak Ristioja <jaak at ristioja dot ee> ---
(In reply to Jaak Ristioja from comment #6)
> PS: At first sight the htonl, htons, ntohl and ntohs macros in
> <netinet/in.h> also appear to require similar casts.

Yep, this does appear to be the case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16458] endian.h and netinet/in.h byte order macros return values of wrong type

[jaak at ristioja dot ee]

https://sourceware.org/bugzilla/show_bug.cgi?id=16458

Jaak Ristioja <jaak at ristioja dot ee> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|endian.h and netinet/in.h   |endian.h and netinet/in.h
                   |byte order macros return    |byte order macros return
                   |unsigned integers of wrong  |values of wrong type
                   |type                        |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16458] endian.h and netinet/in.h byte order macros return values of wrong type

[neleai at seznam dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=16458

--- Comment #8 from Ondrej Bilka <neleai at seznam dot cz> ---
On Thu, Jan 16, 2014 at 07:47:35PM +0000, jaak at ristioja dot ee wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=16458
> 
> --- Comment #6 from Jaak Ristioja <jaak at ristioja dot ee> ---
> (In reply to joseph@codesourcery.com from comment #5)
> > On Thu, 16 Jan 2014, jaak at ristioja dot ee wrote:
> > 
> > > If you insist these being macros, at least the documentation should be fixed
> > > accordingly. Reopening.
> > 
> > "The documentation" for glibc is the Texinfo manual; manpages are an 
> > independent project not covered by this tracker or the glibc maintainers.
> 
> It appears that these interfaces are undocumented in the Texinfo manual.
> 
> Why not just add simple casts to these macros? For example, instead of
> 
>   #   define htobe64(x) __bswap_64 (x)
>   #   define htole64(x) (x)
> 
> use
> 
>   #   define htobe64(x) __bswap_64 ((uint64_t)(x))
>   #   define htole64(x) ((uint64_t)(x))
> 
> PS: At first sight the htonl, htons, ntohl and ntohs macros in <netinet/in.h>
> also appear to require similar casts.
> 
One argument againist this is that we would lose a warning that might be
useful. A better way is add a identity function to do type checking ie:

uint64_t __bkeep_64 (uint64_t x)
{
  return x;
}

define htole64(x) __bkeep_64 (x)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/16458] endian.h and netinet/in.h byte order macros return values of wrong type

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16458

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.