From: Collin Funk <collin.funk1@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>,
"bug-gnulib@gnu.org" <bug-gnulib@gnu.org>
Subject: Re: byteswap.h behavior
Date: Sun, 12 May 2024 12:47:54 -0700 [thread overview]
Message-ID: <bf40370e-abe5-4eb3-a6e6-dbfeaca7ad34@gmail.com> (raw)
In-Reply-To: <f74f59d5-0371-491e-9722-e0a77620e798@cs.ucla.edu>
On 5/12/24 12:38 PM, Paul Eggert wrote:
>> Also if we can agree upon making sure these are defined as functions,
>> what is the proper way to test it in a configure script? My instinct
>> tells me that assigning a function pointer to bswap_16, etc. would
>> fail if they are macros
>
> I don't see the need to check that they are functions. POSIX does not require endian.h symbols like be16toh to be defined as functions, and the glibc manual doesn't mention endian.h, so it sounds like Gnulib-using code shouldn't assume that these symbols are functions.
Yeah, I read the POSIX draft and it says that they may be macros. I
doubt the byteswap.h and endian.h functions are used with non-constant
expression arguments that often.
I worry though that in some cases programs will be accustomed to
glibc's behavior. Since all of the functions are just macros to static
inline functions in <bits/byteswap.h> arguments will only be evaluated
once. It seems like it could be the cause of some unexpected bugs...
Collin
next prev parent reply other threads:[~2024-05-12 19:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-12 19:23 byteswap.h behavior Collin Funk
2024-05-12 19:38 ` Paul Eggert
2024-05-12 19:47 ` Collin Funk [this message]
2024-05-12 20:02 ` Bruno Haible
2024-05-12 20:11 ` Collin Funk
2024-05-12 20:30 ` Paul Eggert
2024-05-12 22:43 ` Collin Funk
2024-05-12 23:10 ` endian.h Bruno Haible
2024-05-12 19:50 ` byteswap.h behavior Jeffrey Walton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bf40370e-abe5-4eb3-a6e6-dbfeaca7ad34@gmail.com \
--to=collin.funk1@gmail.com \
--cc=bug-gnulib@gnu.org \
--cc=eggert@cs.ucla.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).