[I missed this thread, so I'm reposting my reply that I originally sent to source-changes-d]
On Tue, Nov 06, 2018 at 16:38:06 +0000, co...@sdf.org wrote: > On Tue, Nov 06, 2018 at 08:11:03AM -0800, John Nemeth wrote: > > On Nov 6, 3:07pm, co...@sdf.org wrote: > > } > > } I wanna do this, looks good? > > > > No. > > > > } Index: stdint.h > > } =================================================================== > > } RCS file: /cvsroot/src/sys/sys/stdint.h,v > > } retrieving revision 1.7 > > } diff -u -r1.7 stdint.h > > } --- stdint.h 22 Apr 2013 21:26:48 -0000 1.7 > > } +++ stdint.h 4 Nov 2018 09:35:54 -0000 > > } @@ -35,54 +35,54 @@ > > } #include <sys/cdefs.h> > > } #include <machine/int_types.h> > > } > > } -#ifndef int8_t > > } +#ifndef _BSD_INT8_T_ > > } typedef __int8_t int8_t; > > } -#define int8_t __int8_t > > } +#define _BSD_INT8_T_ > > } #endif > > > > What's going to define _BSD_INT8_T_ and friends? > > > > To me, this looks smells like some kind of gross hack to work around > > broken software. > > > > [snip] > > > > }-- End of excerpt from co...@sdf.org > > We are. it's a guard to prevent double type definition. I would argue that the example from https://mail-index.netbsd.org/tech-pkg/2018/10/25/msg020395.html is if not outright wrong then at the very minimum unhygienic, as it doesn't use the same preprocessor nesting for the definition of the name and the use of the name, i.e. it incorrectly assumes that the function will be named "something_uint32_t". Also your change breaks redefining intN_t types with the preprocessor. E.g. #define uint32_t unsigned long long #include <stdint.h> is now broken with your change. -uwe
