On Sat, 4 Feb 2023 at 23:53, Jonathan Wakely wrote:
>
>
> On Sat, 4 Feb 2023, 21:23 Christopher Bazley, wrote:
>
>>
>>
>> On Sat, 4 Feb 2023 at 20:40, Jonathan Wakely
>> wrote:
>>
>>>
>>> On Sat, 4 Feb 2023, 17:01 Christopher Bazley via Gcc,
>>> wrote:
>>>
Does the lack of support fo
Am 24.01.2023 um 19:32 schrieb Ian Lance Taylor:
On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches
wrote:
From: Ian Lance Taylor
Date: Tue, 24 Jan 2023 09:58:10 -0800
Cc: g...@hazardy.de, gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org
I'd rather that the patch look like the appended.
On Sun, 5 Feb 2023, 08:07 Christopher Bazley, wrote:
>
>
> On Sat, 4 Feb 2023 at 23:53, Jonathan Wakely
> wrote:
>
>>
>>
>> On Sat, 4 Feb 2023, 21:23 Christopher Bazley, wrote:
>>
>>>
>>>
>>> On Sat, 4 Feb 2023 at 20:40, Jonathan Wakely
>>> wrote:
>>>
On Sat, 4 Feb 2023, 17:01 Christ
As discussed before, and Bastien and I seem to agree, ideally we should
define the following types:
struct sockaddr_storage {
union {
struct {
sa_family_t ss_family;
};
struct sockaddr_in sin;
struct sockaddr_in6 s
Formatted version:
BUGS
sockaddr_storage was designed back when strict aliasing wasn’t a prob‐
lem. Back then, one would define a variable of that type, and then ac‐
cess it as any of the other sockaddr_* types, depending on the value of
the first member. This is
Snapshot gcc-13-20230205 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20230205/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote:
> As discussed before, and Bastien and I seem to agree, ideally we should
> define the following types:
>
> struct sockaddr_storage {
> union {
> struct {
> sa_family_t ss_family;
>
Hi Rich,
On 2/6/23 00:43, Rich Felker wrote:
On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote:
As discussed before, and Bastien and I seem to agree, ideally we should
define the following types:
struct sockaddr_storage {
union {
struct {
On Mon, Feb 06, 2023 at 12:59:48AM +0100, Alejandro Colomar wrote:
> Hi Rich,
>
> On 2/6/23 00:43, Rich Felker wrote:
> >On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote:
> >>As discussed before, and Bastien and I seem to agree, ideally we should
> >>define the following types:
>
On Sun, Feb 5, 2023 at 1:21 AM Björn Schäpers wrote:
>
> Am 24.01.2023 um 19:32 schrieb Ian Lance Taylor:
> > On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches
> > wrote:
> >>
> >>> From: Ian Lance Taylor
> >>> Date: Tue, 24 Jan 2023 09:58:10 -0800
> >>> Cc: g...@hazardy.de, gcc-pat
On Sun, 2023-02-05 at 16:31 +0100, Alejandro Colomar via Libc-alpha wrote:
> The only correct way to use different types in an API is
> through a union.
I don't think this statement is true (in general). Technically we can
write something like this:
struct sockaddr { ... };
struct socka
12 matches
Mail list logo
