Re: socklen_t data type
Keith Marshall <[email protected]> Mon, 6 Jul 2020 16:11:23 +0100
| Newsgroups | gmane.comp.gnu.mingw.user |
|---|---|
| Organization | MinGW.org Project |
| Message-ID | <[email protected]> |
On 30/06/2020 15:23, Eli Zaretskii wrote:
>> From: Keith Marshall, Tue, 30 Jun 2020 07:54:18 +0100
>>
>>> GDB is a C++ program these days, and is compiled with -fpermissive, so
>>> this causes errors.
>>
>> Surely -fpermissive relaxes the error checking for type conflicts,
>> (possibly among other conditions -- I don't know what its scope is), so
>> such errors would be downgraded to warnings. Do you, perhaps, mean that
>> GDB is compiled _without_ -fpermissive?
>
> You are probably right. All I know is that g++ emitted this:
>
> CXX remote-utils.o
> remote-utils.cc: In function 'void handle_accept_event(int, gdb_client_data)':
> remote-utils.cc:146:69: error: invalid conversion from 'socklen_t*' {aka 'unsigned int*'} to 'int*' [-fpermissive]
> 146 | remote_desc = accept (listen_desc, (struct sockaddr *) &sockaddr, &len);
> | ^~~~
> | |
> | socklen_t* {aka unsigned int*}
>
> I guess I mis-interpreted what that confusing message means to say.
Indeed, it does appear that the error arises because -fpermissive is
enabled, but when I compiled my own test program _without_ -fpermissive,
I got a similar message; when I compiled _with_ -fpermissive, I got the
same message, but downgraded from error to warning.
>> There's more to it. As I reported in:
>>
>> https://savannah.gnu.org/bugs/?57725
>>
>> a primary motivator for the change to unsigned socklen_t was to avoid a
>> proliferation of casts in <wspiapi.h>, (of which, at the time, I seemed
>> to be writing quite a number). Reviewing it again, I seem to have ended
>> up with only one such cast which remains necessary, at line 917:
>>
>> if( (sa == NULL) || (len < sizeof( struct sockaddr )) )
>>
>> With reversion to signed socklen_t, this should become:
>>
>> if( (sa == NULL) || (len < (socklen_t)(sizeof( struct sockaddr ))) )
>
> You are a better judge of this, but to my mind a single cast is a
> small price to pay for avoiding the kind of mess I faced yesterday,
> with socklen_t popping up in compilation errors left and right.
>
> Gnulib already removed the unnecessary conflicting typedef, and I will
> shortly report the problem in the GDB sources to its developers. But
> I think the problems with code which assumes the last argument of
> 'accept' and its ilk could be a 'socklen_t *' are a much harder nut,
> and so going back to a signed int will be a good compromise.
I've made that change, (both change of typedef, and the corresponding
cast), in wsl-5.3.4, which I've uploaded to FRS this morning.
--
Regards,
Keith.
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
_______________________________________________
MinGW-Users mailing list
[email protected]
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.osdn.me/mailman/listinfo/mingw-users
Also: mailto:[email protected]?subject=unsubscribe
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEwZ7AGBVH3lDh1I9TwK02xjR+Wj8FAl8DPxwACgkQwK02xjR+ Wj/Pew//TkTK7XCxdNkcptk7Is4jKasZR/pzDmSOy6fUwgvYagB1iJ3axXpOt2PT HCb8b5fT0K0iEJwewn0XE42omqifokLdmiyymJzwPeHMLssAeTFjWysZPm7H5+4U Tkv47VW5wsXyO6e3LlYT8DLYPlk4jS//9+I0lWrGdFQ3YyroDgDJW0yUObBkPxPn w/ZAo0//wwj7J/51+YIOLjlxTr5mAPTOPnFTvxosr14d2sEpfid+E+jfu3adxdmo /9Wm55HLRz8LkCDUxFrbJ4/cZ+z1oY5dJ8lb5kmRLFufRVwyiHhNmh2Ux+ykD8Bo 6IC2jtzX2d1M4jGQTVU8XGB9slflGDdbuIcwSnfb9vTJGVywMH9PIVdnYijMF2S3 ccGPxycLS6CZ1ceL9ZO0vXDJ06j9SYsPy+SiesxYUQgh85h8my3wCCxHf2SwXl/6 JYd8MRyw62WXexuUNXXwsDLMP3lxjpxeb+ji3ryMCJg5sq2UPK1uUvZlDnG5tjEs USGs7S6YyfdoXtRlPMar97W06GGTO5hPH74CIfnvn9oLReNRUzqCwnRYlflTl3ta LvYh92RL6dJ4zfI7uIdbBLoc08/XGJa3H3ChCqxAaEmjy88Nl4uOyHQBJiDmmerB tSpS84maeF5rY6baAibQQ+dQ+IACzNFNtR++1AlheYfgtDXQtpY= =Bfv7 -----END PGP SIGNATURE-----