Re: Definitions of types also as macros

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

[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, coypu%sdf.org@localhost wrote:

> On Tue, Nov 06, 2018 at 08:11:03AM -0800, John Nemeth wrote:
> > On Nov 6,  3:07pm, coypu%sdf.org@localhost 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 coypu%sdf.org@localhost
> 
> 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