Date: Thu, 01 May 2008 21:16:28 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: Giorgos Keramidas <keramida@ceid.upatras.gr> Cc: =?UTF-8?B?Um9tYWluIO+/vQ==?= <romain@blogreen.org>, Max Laier <max@love2party.net>, hackers@freebsd.org, Romuald Conty <romuald.conty@free.fr>, freebsd-hackers@freebsd.org Subject: Re: indent(1) support for gcc(1) 0b prefix Message-ID: <481A959C.5000704@freebsd.org> In-Reply-To: <8763txlaj6.fsf@kobe.laptop> References: <20080426213557.GA88577@marvin.blogreen.org> <200804270201.53271.max@love2party.net> <8763txlaj6.fsf@kobe.laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>But I would like to use indent(1) to reformat contributed code >>>automatically. Unfortunately, the 0b notation is not supported by that >>>program, and the resulting code looks like this: >>> >>> foo = 0 b00101010; >>> >>>... then compilation fails, bla bla bla... >> >>I can't think of a case (outside of "0x...." context) where "...0b..." >>would be valid C code, let alone better formated as "...0 b...". >>Hence I see no harm in adding your patch to the base indent(1). >> >>Does anyone have an example where "...0 b..." is valid C code? > > The only case I can think of is when the "b..." is an existing macro, > i.e. something like: > > 1 #include <stdio.h> > 2 > 3 #define b0101 + 3 In all of these cases, though, adding a space between the '0' and the 'b' changes the meaning, so is wrong. Indent can change/insert whitespace, but should never do so in a way that changes the meaning of the program. In all of these cases, having indent recognize "0b..." as a single token is the correct behavior. So I don't see any point in having this recognition be tunable. indent already has too many switches. Tim Kientzle
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?481A959C.5000704>