Nabble - Gnu - Indent Tool

Re: can't build indent 2.2.9 from source

2009-12-03T10:29:19Z

On 03/12/09 01:16, Simmons, Aaron wrote:

> I'm trying to build indent 2.2.9 from source, but am getting compile errors:
> source='output.c' object='output.o' libtool=no \
> depfile='.deps/output.Po' tmpdepfile='.deps/output.TPo' \
> depmode=gcc3 /bin/sh ../config/depcomp \
> gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/local/share/locale\" -I. -I. -I.. -I. -I. -I../intl -g -O2 -c `test -f 'output.c' || echo './'`output.c
> output.c:26: error: static declaration of 'output' follows non-static declaration
> indent.h:100: error: previous declaration of 'output' was here
> output.c: In function 'open_output':
> output.c:1149: warning: incompatible implicit declaration of built-in function 'exit'
> make[3]: *** [output.o] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> This same error happens on both Ubuntu Hardy and Mac OS X 10.5.
>
>
>
> aaron
> _______________________________________________
> bug-indent mailing list
> bug-indent@...
> http://lists.gnu.org/mailman/listinfo/bug-indent
>
>

Try 2.2.10

http://directory.fsf.org/project/indent/

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

can't build indent 2.2.9 from source

2009-12-02T16:16:39Z

I'm trying to build indent 2.2.9 from source, but am getting compile errors:
source='output.c' object='output.o' libtool=no \
depfile='.deps/output.Po' tmpdepfile='.deps/output.TPo' \
depmode=gcc3 /bin/sh ../config/depcomp \
gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/local/share/locale\" -I. -I. -I.. -I. -I. -I../intl -g -O2 -c `test -f 'output.c' || echo './'`output.c
output.c:26: error: static declaration of 'output' follows non-static declaration
indent.h:100: error: previous declaration of 'output' was here
output.c: In function 'open_output':
output.c:1149: warning: incompatible implicit declaration of built-in function 'exit'
make[3]: *** [output.o] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

This same error happens on both Ubuntu Hardy and Mac OS X 10.5.

aaron
_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re: How to avoid misformatting of binary values with GNU indent?

2009-11-27T02:02:51Z

Yep, you are right. Its just an extension of gcc (see
http://gcc.gnu.org/onlinedocs/gcc/Binary-constants.html) that make it
compile for me.

Thanks!

indent schrieb:

> On 26/11/09 13:15, Martin Kirsche wrote:
>
>> When GNU indent (at least version 2.2.6 from cygwin and 2.2.10 from
>> GnuWin32) is used on the following code...
>>
>> |void
>> main ()
>> {
>> int i = 0b01010101;
>> }
>> |
>>
>> it will be reformatted into this ...
>>
>> |void
>> main ()
>> {
>> int i = 0 b01010101;
>> }
>> |
>>
>> Is there any option in indent that avoids this behavior?
>>
>>
> No intent doesn't support C derivatives: that construct isn't C. Try the
> hexadecimal 0X55 or octal 0125 which are part of C.
>
>

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re: How to avoid misformatting of binary values with GNU indent?

2009-11-26T10:46:53Z

On 26/11/09 13:15, Martin Kirsche wrote:

> When GNU indent (at least version 2.2.6 from cygwin and 2.2.10 from
> GnuWin32) is used on the following code...
>
> |void
> main ()
> {
> int i = 0b01010101;
> }
> |
>
> it will be reformatted into this ...
>
> |void
> main ()
> {
> int i = 0 b01010101;
> }
> |
>
> Is there any option in indent that avoids this behavior?
>

No intent doesn't support C derivatives: that construct isn't C. Try the
hexadecimal 0X55 or octal 0125 which are part of C.

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

How to avoid misformatting of binary values with GNU indent?

2009-11-26T04:15:40Z

When GNU indent (at least version 2.2.6 from cygwin and 2.2.10 from
GnuWin32) is used on the following code...

|void
main ()
{
int i = 0b01010101;
}
|

it will be reformatted into this ...

|void
main ()
{
int i = 0 b01010101;
}
|

Is there any option in indent that avoids this behavior?

regards, Martin

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

indent -br, -bl options, different number of lines for if (long_conditions) //comment

2009-11-14T02:32:38Z

Hello,

I've tried to indent (GNU indent 2.2.10, Windows) something like this:

int
main ()
{
if (StrCmpNI (aaaaaaaaaaaaaaaaaaaaaaaaaaaaa == 0
|| bbbbbbbbbbbbbbbbbbbbbbbbb == 2
|| ccccccccccccccccccccccccccs (dddd)
|| eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee)) // a comment
{
x ();
}
if (a > 0) {
y ();
}

}

Using -br I've got:
int
main ()
{
if (StrCmpNI (aaaaaaaaaaaaaaaaaaaaaaaaaaaaa == 0
|| bbbbbbbbbbbbbbbbbbbbbbbbb == 2
|| ccccccccccccccccccccccccccs (dddd)
|| eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee)) // a comment
{
x ();
}
if (a > 0) {
y ();
}

}

and using -bl -bli0 I've got:
int
main ()
{
if (StrCmpNI (aaaaaaaaaaaaaaaaaaaaaaaaaaaaa == 0 || bbbbbbbbbbbbbbbbbbbbbbbbb == 2 || ccccccccccccccccccccccccccs (dddd) || eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee)) // a comment
{
x ();
}
if (a > 0)
{
y ();
}

}

Also using again the -br option on the "-bl -bli0" output doesn't change the if condition (it stays on just one line).

It would be nice to have -bl break the if condition on multiple lines or at least keep multiple lines if they are already present (in this case where there is a comment following "if").

I'll put here a diff in case the message gets distorted:

--- E:/a.c.bl Fri Nov 13 00:34:44 2009
+++ E:/a.c.br Fri Nov 13 00:34:37 2009

@@ -1,13 +1,15 @@
int
main ()
{
- if (StrCmpNI (aaaaaaaaaaaaaaaaaaaaaaaaaaaaa == 0 || bbbbbbbbbbbbbbbbbbbbbbbbb == 2 || ccccccccccccccccccccccccccs (dddd) || eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee)) // a comment
+ if (StrCmpNI (aaaaaaaaaaaaaaaaaaaaaaaaaaaaa == 0
+ || bbbbbbbbbbbbbbbbbbbbbbbbb == 2
+ || ccccccccccccccccccccccccccs (dddd)
+ || eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee)) // a comment
{
x ();
}
- if (a > 0)
- {
+ if (a > 0) {
y ();
}

}

Thank you for your time,
Andrei

--

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

indent -br, -bl options, different number of lines for if (long_conditions) //comment

2009-11-12T14:42:45Z

Re: [PATCH] fix indent handling of range in case statements

2009-11-11T11:21:24Z

le mercredi 11 novembre 2009 indent a écrit
> I haven't got around to merging it yet, but just looking at the patch
> lines it seemed acceptable - although you did not honour the coding style.
> I would point out that there are a number of problems with C++ code
> (which language "..." is part of and not C) that can break the code, so
> be careful using indent on C++.

I ran into this "bug" using indent on qemu source code which is not C++
(although it might certainly use some C++ style constructs supported by gcc).

That's why I tried to fix it.

JC

> Jean-Christophe Dubois wrote:
> > Just curious: Is this patch accepted or is it inadequate for some reason?
> >
> > I got no feed back on this proposed patch.
> >
> > JC
> >
> > le jeudi 1 octobre 2009 Jean-Christophe Dubois a écrit
> >
> >> indent is not handling correctly case statements dealing with values
> >> range.
> >>
> >> For example:
> >>
> >> case 0x01 ... 0x0b:
> >>
> >> Will be transformed by indent in:
> >>
> >> case 0x01...0 x0b:
> >>
> >> Which cannot compile.
> >>
> >> This patch tries to fix this issue. I am not sure this is the correct
> >> solution but it seems to work for me.
> >>
> >> Signed-off-by: Jean-Christophe Dubois <jcd@...>
> >>
> >> --- indent-2.2.10.org/src/lexi.c 2008-03-11 19:50:42.000000000 +0100
> >> +++ indent-2.2.10/src/lexi.c 2009-10-01 01:22:09.349653276 +0200
> >> @@ -938,28 +938,38 @@
> >> break;
> >>
> >> case '.':
> >> - if (parser_state_tos->in_decl &&
> >> - (buf_ptr[0] == '.') &&
> >> + if ((buf_ptr[0] == '.') &&
> >> (buf_ptr[1] == '.'))
> >> {
> >> - /* check for '...' in a declaration */
> >> + /* We have a '...'. This is supposed to mean something */
> >> if ((buf_ptr += 2) >= buf_end)
> >> {
> >> fill_buffer();
> >> }
> >>
> >> - unary_delim = true;
> >> - code = decl;
> >> - token_end = buf_ptr;
> >> - break;
> >> - }
> >> - unary_delim = false;
> >> - code = struct_delim;
> >> + if (parser_state_tos->in_decl)
> >> + {
> >> + /* this is '...' in a declaration */
> >> + unary_delim = true;
> >> + code = decl;
> >> + token_end = buf_ptr;
> >> + } else {
> >> + /* this is '...' somewhere else */
> >> + /* for example: case 1 ... 9: */
> >> + unary_delim = true;
> >> + code = binary_op;
> >> + token_end = buf_ptr;
> >> + }
> >> + } else {
> >> +
> >> + unary_delim = false;
> >> + code = struct_delim;
> >>
> >> - if (*buf_ptr == '*') /* object .* pointer-to-member */
> >> - {
> >> - ++buf_ptr;
> >> - token_end = buf_ptr;
> >> + if (*buf_ptr == '*') /* object .* pointer-to-member */
> >> + {
> >> + ++buf_ptr;
> >> + token_end = buf_ptr;
> >> + }
> >> }
> >> break;
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> bug-indent mailing list
> >> bug-indent@...
> >> http://lists.gnu.org/mailman/listinfo/bug-indent
> >
> > _______________________________________________
> > bug-indent mailing list
> > bug-indent@...
> > http://lists.gnu.org/mailman/listinfo/bug-indent
>

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re: [PATCH] fix indent handling of range in case statements

2009-11-11T10:44:24Z

I haven't got around to merging it yet, but just looking at the patch
lines it seemed acceptable - although you did not honour the coding style.
I would point out that there are a number of problems with C++ code
(which language "..." is part of and not C) that can break the code, so
be careful using indent on C++.

Jean-Christophe Dubois wrote:

> Just curious: Is this patch accepted or is it inadequate for some reason?
>
> I got no feed back on this proposed patch.
>
> JC
>
> le jeudi 1 octobre 2009 Jean-Christophe Dubois a écrit
>
>> indent is not handling correctly case statements dealing with values range.
>>
>> For example:
>>
>> case 0x01 ... 0x0b:
>>
>> Will be transformed by indent in:
>>
>> case 0x01...0 x0b:
>>
>> Which cannot compile.
>>
>> This patch tries to fix this issue. I am not sure this is the correct
>> solution but it seems to work for me.
>>
>> Signed-off-by: Jean-Christophe Dubois <jcd@...>
>>
>> --- indent-2.2.10.org/src/lexi.c 2008-03-11 19:50:42.000000000 +0100
>> +++ indent-2.2.10/src/lexi.c 2009-10-01 01:22:09.349653276 +0200
>> @@ -938,28 +938,38 @@
>> break;
>>
>> case '.':
>> - if (parser_state_tos->in_decl &&
>> - (buf_ptr[0] == '.') &&
>> + if ((buf_ptr[0] == '.') &&
>> (buf_ptr[1] == '.'))
>> {
>> - /* check for '...' in a declaration */
>> + /* We have a '...'. This is supposed to mean something */
>> if ((buf_ptr += 2) >= buf_end)
>> {
>> fill_buffer();
>> }
>>
>> - unary_delim = true;
>> - code = decl;
>> - token_end = buf_ptr;
>> - break;
>> - }
>> - unary_delim = false;
>> - code = struct_delim;
>> + if (parser_state_tos->in_decl)
>> + {
>> + /* this is '...' in a declaration */
>> + unary_delim = true;
>> + code = decl;
>> + token_end = buf_ptr;
>> + } else {
>> + /* this is '...' somewhere else */
>> + /* for example: case 1 ... 9: */
>> + unary_delim = true;
>> + code = binary_op;
>> + token_end = buf_ptr;
>> + }
>> + } else {
>> +
>> + unary_delim = false;
>> + code = struct_delim;
>>
>> - if (*buf_ptr == '*') /* object .* pointer-to-member */
>> - {
>> - ++buf_ptr;
>> - token_end = buf_ptr;
>> + if (*buf_ptr == '*') /* object .* pointer-to-member */
>> + {
>> + ++buf_ptr;
>> + token_end = buf_ptr;
>> + }
>> }
>> break;
>>
>>
>>
>>
>> _______________________________________________
>> bug-indent mailing list
>> bug-indent@...
>> http://lists.gnu.org/mailman/listinfo/bug-indent
>>
>>
>
>
>
> _______________________________________________
> bug-indent mailing list
> bug-indent@...
> http://lists.gnu.org/mailman/listinfo/bug-indent
>
>

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re: [PATCH] fix indent handling of range in case statements

2009-11-11T06:08:58Z

Just curious: Is this patch accepted or is it inadequate for some reason?

I got no feed back on this proposed patch.

JC

le jeudi 1 octobre 2009 Jean-Christophe Dubois a écrit

> indent is not handling correctly case statements dealing with values range.
>
> For example:
>
> case 0x01 ... 0x0b:
>
> Will be transformed by indent in:
>
> case 0x01...0 x0b:
>
> Which cannot compile.
>
> This patch tries to fix this issue. I am not sure this is the correct
> solution but it seems to work for me.
>
> Signed-off-by: Jean-Christophe Dubois <jcd@...>
>
> --- indent-2.2.10.org/src/lexi.c 2008-03-11 19:50:42.000000000 +0100
> +++ indent-2.2.10/src/lexi.c 2009-10-01 01:22:09.349653276 +0200
> @@ -938,28 +938,38 @@
> break;
>
> case '.':
> - if (parser_state_tos->in_decl &&
> - (buf_ptr[0] == '.') &&
> + if ((buf_ptr[0] == '.') &&
> (buf_ptr[1] == '.'))
> {
> - /* check for '...' in a declaration */
> + /* We have a '...'. This is supposed to mean something */
> if ((buf_ptr += 2) >= buf_end)
> {
> fill_buffer();
> }
>
> - unary_delim = true;
> - code = decl;
> - token_end = buf_ptr;
> - break;
> - }
> - unary_delim = false;
> - code = struct_delim;
> + if (parser_state_tos->in_decl)
> + {
> + /* this is '...' in a declaration */
> + unary_delim = true;
> + code = decl;
> + token_end = buf_ptr;
> + } else {
> + /* this is '...' somewhere else */
> + /* for example: case 1 ... 9: */
> + unary_delim = true;
> + code = binary_op;
> + token_end = buf_ptr;
> + }
> + } else {
> +
> + unary_delim = false;
> + code = struct_delim;
>
> - if (*buf_ptr == '*') /* object .* pointer-to-member */
> - {
> - ++buf_ptr;
> - token_end = buf_ptr;
> + if (*buf_ptr == '*') /* object .* pointer-to-member */
> + {
> + ++buf_ptr;
> + token_end = buf_ptr;
> + }
> }
> break;
>
>
>
>
> _______________________________________________
> bug-indent mailing list
> bug-indent@...
> http://lists.gnu.org/mailman/listinfo/bug-indent
>

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re: option for space between a template class name and the following angle bracket

2009-11-06T23:38:18Z

Harun Abi wrote:

I realize it is popular on this list to make the claim of "indent is only
for c" but that is in fact, bullshit.

That is not a claim it is a statement of policy.

It handles c++ well in many areas because it is coded to handle c++ well
in many areas.
...

It also handles C++ extremely badly in many areas and many updates to fix
this broke C handling, so the decision was made not to continue to try.
Further some of the things you listed are actually in the C standard now.

The gatekeepers should be a little friendlier to accepting changes to add
in the rest of the c++ handling so it can officially handle indenting
both.

I did not see any changes coming from you that could be accepted, only an
empty-handed suggestion for a change. It is not my policy to reject supplied
code updates, if they are well engineered, documented and proven not to
break existing behaviour.
_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re: option for space between a template class name and the following angle bracket

2009-11-06T12:39:44Z

I realize it is popular on this list to make the claim of "indent is only
for c" but that is in fact, bullshit.

It handles c++ well in many areas because it is coded to handle c++ well in
many areas.

C:\TEMP\INDENT-2.2.10\src\args.c(332): {"c++",
PRO_BOOL, false, ON,
&settings.c_plus_plus, &exp_cpp},
C:\TEMP\INDENT-2.2.10\src\args.c(451): {"c++",
PRO_BOOL, false, ON,
&settings.c_plus_plus, &exp_cpp},
C:\TEMP\INDENT-2.2.10\src\args.c(577):
{"c-plus-plus", "c++"},
C:\TEMP\INDENT-2.2.10\src\args.c(930): * The first 2 characters of a c++
comment have been read skip the remainder of the line
C:\TEMP\INDENT-2.2.10\src\code_io.c(417): * off formatting (a comment, C or
C++, beginning with *INDENT-OFF*),
C:\TEMP\INDENT-2.2.10\src\comments.c(48): * both C and C++ comments.
C:\TEMP\INDENT-2.2.10\src\comments.c(136): /* First, decide what kind of
comment this is: C++, C, or boxed C.
C:\TEMP\INDENT-2.2.10\src\comments.c(496): /* We may be at the end
of a C++ comment */
C:\TEMP\INDENT-2.2.10\src\indent.c(867): * "
private:\n" C++, treat as label.
C:\TEMP\INDENT-2.2.10\src\indent.c(875): * " unsigned int
private:4\n" C/C++, treat as bits.
C:\TEMP\INDENT-2.2.10\src\indent.c(1527): /* handle C++ const function
declarations like
C:\TEMP\INDENT-2.2.10\src\indent.c(2302): /* Deal with C++
Class::Method */
C:\TEMP\INDENT-2.2.10\src\indent.c(2347): /* Handle C++ operator
overloading like:
C:\TEMP\INDENT-2.2.10\src\indent.c(2367): /* Handle C++ operator
overloading. See case overloaded above. */
C:\TEMP\INDENT-2.2.10\src\indent.c(2396): /* A C or C++ comment.
*/
C:\TEMP\INDENT-2.2.10\src\indent.h(305): int c_plus_plus; /*!< True if
we're handling C++ code. */
C:\TEMP\INDENT-2.2.10\src\indent.h(464): char *classname;
/*!< The name of the current C++ class */
C:\TEMP\INDENT-2.2.10\src\lexi.c(207):/* Include code generated by gperf for
C++ keyword set */
C:\TEMP\INDENT-2.2.10\src\lexi.c(476): case rw_operator: /* C++
operator overloading. */
C:\TEMP\INDENT-2.2.10\src\lexi.c(858): /* Deal with C++ class::method
*/
C:\TEMP\INDENT-2.2.10\src\lexi.c(1054): /* in C++ mode also scan <?[=],
>?[=] GNU C++ operators
C:\TEMP\INDENT-2.2.10\src\lexi.c(1081): /* A C or C++ comment */
C:\TEMP\INDENT-2.2.10\src\lexi.c(1121): /* For C++ overloaded
operators. */
C:\TEMP\INDENT-2.2.10\src\lexi.h(29): rw_operator, /*!< For C++
operator overloading. */
C:\TEMP\INDENT-2.2.10\src\lexi.h(59): doublecolon, /*!< For C++
class methods. */
C:\TEMP\INDENT-2.2.10\src\lexi.h(67): overloaded, /*!< For C++
overloaded operators (like +) */
C:\TEMP\INDENT-2.2.10\src\lexi.h(72): cplus_comment, /*!< A C++
"slash-slash" */
C:\TEMP\INDENT-2.2.10\src\libgettext.h(52):/* Many header files from the
libstdc++ coming with g++ 3.3 or newer include

Is all that in the c standard?

The gatekeepers should be a little friendlier to accepting changes to add in
the rest of the c++ handling so it can officially handle indenting both.

On Fri, Nov 6, 2009 at 3:04 PM, indent <indent@...> wrote:

> indent is a tool for indenting C code.
> templates are not in the C standard.
>
> Kiwon Um wrote:
> > Dear GNU Indent Dev. Team:
> >
> > This mail suggests an options for template-related formatting
> > control. GNU Indent does format as follow:
> >
> > shared_ptr < Test > test;
> > const int R = static_cast < int >(pow(2.0f, 6));
> >
> > It has a lot of options for parenthesis, but not for angle
> > bracket. Therefore, I suggest some options to control space between a
> > template class name and the following angle bracket so that the
> > followings are possible:
> >
> > shared_ptr<Test> test;
> > const int R = static_cast<int>(pow(2.0f, 6));
> >
> > Thank you.
> >
> > Sincerely,
> >
> > Kiwon Um
> >
> >
> > _______________________________________________
> > bug-indent mailing list
> > bug-indent@...
> > http://lists.gnu.org/mailman/listinfo/bug-indent
> >
> >
>
>
>
> _______________________________________________
> bug-indent mailing list
> bug-indent@...
> http://lists.gnu.org/mailman/listinfo/bug-indent
>

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re: option for space between a template class name and the following angle bracket

2009-11-06T12:04:27Z

indent is a tool for indenting C code.
templates are not in the C standard.

Kiwon Um wrote:

> Dear GNU Indent Dev. Team:
>
> This mail suggests an options for template-related formatting
> control. GNU Indent does format as follow:
>
> shared_ptr < Test > test;
> const int R = static_cast < int >(pow(2.0f, 6));
>
> It has a lot of options for parenthesis, but not for angle
> bracket. Therefore, I suggest some options to control space between a
> template class name and the following angle bracket so that the
> followings are possible:
>
> shared_ptr<Test> test;
> const int R = static_cast<int>(pow(2.0f, 6));
>
> Thank you.
>
> Sincerely,
>
> Kiwon Um
>
>
> _______________________________________________
> bug-indent mailing list
> bug-indent@...
> http://lists.gnu.org/mailman/listinfo/bug-indent
>
>

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

option for space between a template class name and the following angle bracket

2009-11-06T01:49:51Z

Dear GNU Indent Dev. Team:

This mail suggests an options for template-related formatting
control. GNU Indent does format as follow:

shared_ptr < Test > test;
const int R = static_cast < int >(pow(2.0f, 6));

It has a lot of options for parenthesis, but not for angle
bracket. Therefore, I suggest some options to control space between a
template class name and the following angle bracket so that the
followings are possible:

shared_ptr<Test> test;
const int R = static_cast<int>(pow(2.0f, 6));

Thank you.

Sincerely,

Kiwon Um

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re: annoying misbehavior of -linux in 2.2.10

2009-11-05T09:52:00Z

The FOO problem looks like a bug.
the poink problem can be fixed with the -T foo option.

Alejandro Mery wrote:

> Hello,
>
> I mail you to ask how to "fix" two annoying misbehaviors (imo), one is
> an extra space injected before macro names when used inside structs
> and the other is an space after the * when they type is a typedef.
>
> the test file (attached) looks like:
> ---
> typedef int foo;
>
> #define FOO(N) foo N
>
> struct bar {
> foo i;
> FOO(j);
> };
>
> void poink(foo *i, int *j);
> ---
>
> and `indent -linux test.c` makes the following (imo invalid) change
>
> --- test.c~ 2009-10-15 12:59:18.000000000 +0200
> +++ test.c 2009-10-15 12:59:21.000000000 +0200
> @@ -4,7 +4,7 @@
>
> struct bar {
> foo i;
> - FOO(j);
> + FOO(j);
> };
>
> -void poink(foo *i, int *j);
> +void poink(foo * i, int *j);
>
> I'm using 2.2.10 from Ubuntu. Is there a way to fix this by arguments?
>
> Thanks,
> Alejandro Mery
> ------------------------------------------------------------------------
>
> _______________________________________________
> bug-indent mailing list
> bug-indent@...
> http://lists.gnu.org/mailman/listinfo/bug-indent

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

annoying misbehavior of -linux in 2.2.10

2009-10-15T04:16:37Z

Hello,

I mail you to ask how to "fix" two annoying misbehaviors (imo), one
is an extra space injected before macro names when used inside
structs and the other is an space after the * when they type is a
typedef.

the test file (attached) looks like:
---
typedef int foo;

#define FOO(N) foo N

struct bar {
foo i;
FOO(j);
};

void poink(foo *i, int *j);
---

and `indent -linux test.c` makes the following (imo invalid) change

--- test.c~ 2009-10-15 12:59:18.000000000 +0200
+++ test.c 2009-10-15 12:59:21.000000000 +0200
@@ -4,7 +4,7 @@

struct bar {
foo i;
- FOO(j);
+ FOO(j);
};

-void poink(foo *i, int *j);
+void poink(foo * i, int *j);

I'm using 2.2.10 from Ubuntu. Is there a way to fix this by arguments?

Thanks,
Alejandro Mery

[test.c]

typedef int foo; #define FOO(N) foo N struct bar { foo i; FOO(j); }; void poink(foo *i, int *j);

[test.diff]

--- test.c~ 2009-10-15 12:59:18.000000000 +0200 +++ test.c 2009-10-15 12:59:21.000000000 +0200 @@ -4,7 +4,7 @@ struct bar { foo i; - FOO(j); + FOO(j); }; -void poink(foo *i, int *j); +void poink(foo * i, int *j);

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

smime.p7s (6K) Download Attachment

Re: GNU indent 2.2.10 bug ?

2009-10-06T10:56:53Z

k9jenius@... wrote:

> I'm using GNU indent version 2.2.10 on a Slackware 13.0 64 bit system.
>
> The texinfo page says any space between a # and "include" is removed by default.
> If you want to leave it the space, then one should use the -lps option.
>
> Given this one line source file (call it test.c) that has 1 space between
> the # and "include":
>
> # include <stdio.h>
>
> if I run
>
> indent -st test.c
>
> indent does not make any changes to the file: the space between the # and include
> is left intact. Just to make sure the default wasn't to leave the space, I
> tried:
>
> indent -nlps test.c
>
> and again indent did nothing: the space between the # and include was maintained.
>
> in other words, the -nlps option (which is the default) does not work for me.
>
> I found this while running indent on a much larger file where indent did do
> a lot of clean up for me. Perhaps I'm misunderstanding what the -nlps
> option is supposed to do, I dunno. I would appreciate it if someone
> could kindly look into this and let me know if if you believe it is a
> bug.
>
>

Looks like a bug, thanks for reporting it. It seems the regression tests
only test for the opposite action of inserting spaces :-(

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

GNU indent 2.2.10 bug ?

2009-10-04T20:18:34Z

I'm using GNU indent version 2.2.10 on a Slackware 13.0 64 bit system.

The texinfo page says any space between a # and "include" is removed by default.
If you want to leave it the space, then one should use the -lps option.

Given this one line source file (call it test.c) that has 1 space between
the # and "include":

# include <stdio.h>

if I run

indent -st test.c

indent does not make any changes to the file: the space between the # and include
is left intact. Just to make sure the default wasn't to leave the space, I
tried:

indent -nlps test.c

and again indent did nothing: the space between the # and include was maintained.

in other words, the -nlps option (which is the default) does not work for me.

I found this while running indent on a much larger file where indent did do
a lot of clean up for me. Perhaps I'm misunderstanding what the -nlps
option is supposed to do, I dunno. I would appreciate it if someone
could kindly look into this and let me know if if you believe it is a
bug.

Kind Regards,

Paul Novak
k9jenius@...

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

[PATCH] fix indent handling of range in case statements

2009-10-01T13:27:33Z

indent is not handling correctly case statements dealing with values range.

For example:

case 0x01 ... 0x0b:

Will be transformed by indent in:

case 0x01...0 x0b:

Which cannot compile.

This patch tries to fix this issue. I am not sure this is the correct
solution but it seems to work for me.

Signed-off-by: Jean-Christophe Dubois <jcd@...>

--- indent-2.2.10.org/src/lexi.c 2008-03-11 19:50:42.000000000 +0100
+++ indent-2.2.10/src/lexi.c 2009-10-01 01:22:09.349653276 +0200
@@ -938,28 +938,38 @@
break;

case '.':
- if (parser_state_tos->in_decl &&
- (buf_ptr[0] == '.') &&
+ if ((buf_ptr[0] == '.') &&
(buf_ptr[1] == '.'))
{
- /* check for '...' in a declaration */
+ /* We have a '...'. This is supposed to mean something */
if ((buf_ptr += 2) >= buf_end)
{
fill_buffer();
}

- unary_delim = true;
- code = decl;
- token_end = buf_ptr;
- break;
- }
- unary_delim = false;
- code = struct_delim;
+ if (parser_state_tos->in_decl)
+ {
+ /* this is '...' in a declaration */
+ unary_delim = true;
+ code = decl;
+ token_end = buf_ptr;
+ } else {
+ /* this is '...' somewhere else */
+ /* for example: case 1 ... 9: */
+ unary_delim = true;
+ code = binary_op;
+ token_end = buf_ptr;
+ }
+ } else {
+
+ unary_delim = false;
+ code = struct_delim;

- if (*buf_ptr == '*') /* object .* pointer-to-member */
- {
- ++buf_ptr;
- token_end = buf_ptr;
+ if (*buf_ptr == '*') /* object .* pointer-to-member */
+ {
+ ++buf_ptr;
+ token_end = buf_ptr;
+ }
}
break;

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

YURIZANDER

2009-09-17T16:11:19Z

ME GUSTA TENER AMIGOS, QUISIERA QUE ME ESCRIBIERAN. CHAOO Y QUE DIOS LOS BENDIGA.
--
Este mensaje ha sido analizado por MailScanner Nodo Finlay, Camaguey, Cuba
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.

Visite nuestro sitio http://nodofinlay.cmw.sld.cu

--

Este mensaje le ha llegado mediante el servicio de correo electronico
que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistem
a Nacional de Salud. La persona que envia este correo asume el compromiso de
usar el servicio a tales fines y cumplir con las regulaciones establecidas

Infomed: http://www.sld.cu/

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re: more probably bugreport than a wish

2009-08-24T23:33:58Z

Andrey Utkin wrote:

> Hi, and long life the GNU developers!
>
> indent inserts tabulation symbols into mid-line (for example, between the
> declaration and the comment). Having \t`s inside the line is unacceptable,
> spaces must be used for alignment. Tabs can take place in a line beginning.
> Because, if we have tabs in middle of line, the line end position depends on
> a number of spaces used to represent a tab in user`s viewer. This leads to
> that lines with same indentation level have their endings glissading, even
> if they were aligned before running `indent`.
> Well, i just want to say that the option is necessary, that`ll result in
> having no tabs mid-line.
>
> If you need more details, and examples of what i mean, i`ll provide you with
> them.
>

No bug and no need to wish.

Use the -nut switch. (or -no-tabs)

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

more probably bugreport than a wish

2009-08-21T08:15:02Z

Hi, and long life the GNU developers!

indent inserts tabulation symbols into mid-line (for example, between the
declaration and the comment). Having \t`s inside the line is unacceptable,
spaces must be used for alignment. Tabs can take place in a line beginning.
Because, if we have tabs in middle of line, the line end position depends on
a number of spaces used to represent a tab in user`s viewer. This leads to
that lines with same indentation level have their endings glissading, even
if they were aligned before running `indent`.
Well, i just want to say that the option is necessary, that`ll result in
having no tabs mid-line.

If you need more details, and examples of what i mean, i`ll provide you with
them.
--
Andrey Utkin
_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

missing space after a comma

2009-08-10T17:42:09Z

Hi,

I'm developing an USB Wifi driver for Linux, and I've found that a
file was not passing scripts/checkpatch after applying scripts/Lindent
which is a wrapper around indent. Lindent uses '-npro -kr -i8 -ts8
-sob -l80 -ss -ncs -cp1 -il0' as flags for indent.

before:
static struct ieee80211_rate wbsoft_rates[] = {
{ .bitrate = 10, .flags = IEEE80211_RATE_SHORT_PREAMBLE },
};

after:
static struct ieee80211_rate wbsoft_rates[] = {
{.bitrate = 10,.flags = IEEE80211_RATE_SHORT_PREAMBLE},
};

(note the missing whitespace after the first comma.)

The file is linux-2.6.30.4/drivers/staging/winbond/wbusb.c and I have
the latest stable version of indent on a Gentoo system.

amore@t60 ~ $ indent --version
GNU indent 2.2.9
amore@t60 ~ $ cat /etc/gentoo-release
Gentoo Base System release 1.12.11.1

Hope it helps...

Thanks!

--
Andres

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Bug#536797: indent: [unix hatable] doesn't do proper backups of files in dangerous situations (fwd)

2009-07-25T11:04:50Z

Hello.

I received this from the Debian bug system:

---------- Forwarded message ----------
From: "Eddy [UTF-8] Petrior" <eddy.petrisor@...>
To: Debian Bug Tracking System <submit@...>
Date: Mon, 13 Jul 2009 19:10:44 +0300
Subject: Bug#536797: indent: [unix hatable] doesn't do proper backups of files
in dangerous situations

Package: indent
Version: 2.2.10-1
Severity: important

Hello,

In the second chapter of the "Unix haters" book (named "Welcome, New
User!"), in the subchapter "Error Messages and Error Checking, NOT!"
there is a quote of a message from Pavel Curtis sent in 1992 to the
Unix haters mailing list. I am quoting a part from that message:

========================================
I attempt to type:
% ident foo
to see what versions of what source files are included in the execut-
able. [Never mind that RCS is obviously the wrong thing or that the
way ÿÿidentÿÿ works is unbelievably barbaric; I have bigger fish to
fry...]
Of course, though, on this occasion I mistyped as my fingers go on
autopilot and prefer the word ÿÿindentÿÿ to the non-word ÿÿident:ÿÿ
% indent foo
Now, it turns out that ÿÿindentÿÿ is the name of UNIXÿÿs brain-damaged
idea of a prettyprinter for C. Did the bastard who wrote this abortion
consider checking to make sure that its input was a C file (like, oh
my god, checking for whether or not the name ended in ÿÿ.cÿÿ)? I think
you know the answer. Further, Said Bastard decided that if you give
only one argument to indent then you must mean for the source code
to be prettyprinted in place, overwriting the old contents of the file.
But not to worry, SB knew you might be worried about the damage
this might do, so SB made sure to save a copy of your old contents in
foo.BAK. Did SB simply rename foo to foo.BAK? Of course not, far
better to copy all of the bits out of foo into foo.BAK, then truncate
the file foo, than to write out the new, prettyprinted file. Bastard.

========================================

Unfortunately, it seems that, 17 years later, the current indent
command still is broken and fails to make proper backups, as this set
of commands proves:

0 eddy@twix /tmp/unixhaters $ cp /bin/bash .
0 eddy@twix /tmp/unixhaters $ md5sum /bin/bash bash
c8770eb0a3f2b6088914b4bc29301113 /bin/bash
c8770eb0a3f2b6088914b4bc29301113 bash
0 eddy@twix /tmp/unixhaters $ indent bash
indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

indent: bash:1: Warning:Warning: File bash contains NULL-characters

0 eddy@twix /tmp/unixhaters $ md5sum /bin/bash bash bash~
c8770eb0a3f2b6088914b4bc29301113 /bin/bash
fdd37c28b05dfbe6317facfc72f3059e bash
f0e8f38aa2e7c1e64ce367b934453e76 bash~

It would probably be a good idea to make sure that:
- the original file is renamed instead of copied (badly)
- the original file is a text file, more exactly a C file
- the command stops if it seems the file is binary (or at least asks
for a confirmation, if it detects such a situation)

--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Bug#487517: indent: [rfe] better support for gettext macros (fwd)

2009-07-24T11:27:39Z

Hello.

Received this from the Debian BTS:

---------- Forwarded message ----------
From: Hamish <hamish_b@...>
To: Debian Bug Tracking System <submit@...>
Date: Sun, 22 Jun 2008 23:39:09 +1200
Subject: Bug#487517: indent: [rfe] better support for gettext macros

Package: indent
Version: 2.2.9-7
Severity: wishlist
Tags: l10n

Hi,

At the GRASS GIS project (grass.osgeo.org) we are preparing to re-indent
our c. 1M SLOC codebase. Trials have shown that indent sometimes does
not do well with the _("") gettext macros used for i18n of messages.
For example,

indent produces:
G_fatal_error
(_
("Can't get projection info of current location

better would be to break lines like:
G_fatal_error(
_("Can't get projection info ....

CLI rules used:
$ indent -bad -bap -bbb -br -bli0 -bls -cli0 -ncs -fc1 -hnl -i4 \
-nbbo -nbc -nbfda -nbfde -ncdb -ncdw -nce -nfca -npcs -nprs \
-npsl -nsc -nsob -saf -sai -saw -sbi0 -ss -ts8 -ut main.c

Example code which upon indent'ing shows the behaviour:
http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.sun/main.c

refs:
http://thread.gmane.org/gmane.comp.gis.grass.devel/26820/focus=27382
http://trac.osgeo.org/grass/browser/grass/trunk/SUBMITTING#L229

thanks,
Hamish

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Bug#536527: -dj option doesn't take parameter. (fwd)

2009-07-24T11:25:28Z

Hello.

Received this from the Debian BTS:

---------- Forwarded message ----------
From: "Marco [UTF-8] Túlio Gontijo e Silva" <marcot@...>
To: Debian Bug Tracking System <submit@...>
Date: Fri, 10 Jul 2009 16:43:27 -0300
Subject: Bug#536527: -dj option doesn't take parameter.

Package: indent
Version: 2.2.10-1
Severity: minor

The -dj option doesn't take parameter, but it's shown as -djn in the manpage.

[...]

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Bug#535601: Indent changes file twice when called twice (fwd)

2009-07-24T11:20:25Z

Hello.

I received this from the Debian bug system:

---------- Forwarded message ----------
From: Joachim Zobel <jzobel@...>
To: submit@...
Date: Fri, 03 Jul 2009 08:12:49 +0200
Subject: Bug#535601: Indent changes file twice when called twice

Package: indent
Version: 2.2.10-1
Severity: normal

We have found that indent changes some files back and forth. Here is an
example that reproduces the problem:

jzobel@test$ cp test_indent.c test_indent.c.org
jzobel@test$ indent -kr --no-tabs test_indent.c
jzobel@test$ diff test_indent.c test_indent.c.org
18,19c18,19
< return
bar->bar->bar->bar->bar->bar->bar->bar->bar->bar->bar->bar->
< bar->bar->bar->bar->bar;
---
> return bar->bar->bar->bar->bar->bar->bar->bar->bar->bar->bar->
> bar->bar->bar->bar->bar->bar;
jzobel@test$ indent -kr --no-tabs test_indent.c
jzobel@test$ diff test_indent.c test_indent.c.org
jzobel@test$

Sincerely,
Joachim

[test_indent.c]

/* *********************************************************************** * * * Test for an indent bug. * * * *********************************************************************** */ /* Test for an indent bug */ void foo() { return bar->bar->bar->bar->bar->bar->bar->bar->bar->bar->bar-> bar->bar->bar->bar->bar->bar; }

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Bug#507173: indent: adds extra const keywords to C++ programs (fwd)

2009-07-24T11:17:50Z

Hello.

I received this from the Debian bug system.
There is a proposed patch at the end.

---------- Forwarded message ----------
From: Timo Juhani Lindfors <timo.lindfors@...>
To: Debian Bug Tracking System <submit@...>
Date: Fri, 28 Nov 2008 20:49:35 +0200
Subject: Bug#507173: indent: adds extra const keywords to C++ programs

Package: indent
Version: 2.2.10-1
Severity: normal

Steps to reproduce:
1) cat > svg.cc <<EOF
void Svg::write(std::ostream &st, const Graph &g) const { }
EOF
2) indent -o svg.cc.indent svg.cc

Expected results:
2) svg.cc.indent and svg.cc differ only in whitespace

Actual results:
2) svg.cc.indent has extra const keyword:

void
Svg::write (std::ostream & st, const Graph & g) const const
{
}

More info:
1) If I run indent again to the output file it adds yet another const
keyword. This means that indent is not idempotent and can not be used
to check whether a file already has correct indentation or not.
2) The bug also occurs with indent 2.2.9-7 in debian stable.
3) It seems that the first const is written by handle_token_decl() and
the second const is written by copy_id():

case decl:
/* we have a declaration type (int, register, etc.) */

handle_token_decl(dec_ind, file_exit_value,
pbreak_line);

copy_id(type_code, force_nl, file_exit_value, can_break);

Maybe this could be fixed by just not writing const from
handle_token_decl?

-----------------------------------------------------------
Later, Erwin Burgstaller <burgstal@...> writes:

I've found this patch and it's working:

--- indent.c.orig Tue Jan 31 18:00:29 2006
+++ indent.c Sat Sep 2 12:48:07 2006
@@ -1439,6 +1439,7 @@
{
char * t_ptr;
set_buf_break (bb_const_qualifier, paren_target);
+#if 0 /* fix doubling of C++ tokens */
*e_code++ = ' ';

for (t_ptr = token; t_ptr < token_end; ++t_ptr)
@@ -1448,6 +1449,7 @@
}

*e_code = '\0'; /* null terminate code sect */
+#endif /* fix doubling of C++ tokens */
}
else
{

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Segfault in current_column()?

2009-06-14T15:08:42Z

indent developers:

I believe there is a flaw in the current_column routine inside
code_io.c, because when p is assigned to cur_line, the while-loop which
tests p against buf_ptr will result in segmentation fault since cur_line
is inside a different buffer context than buf_ptr...at least as far I
can tell with gdb.

My naive solution is included below (adapted from the 2.2.10). I
introduce a "once" flag which forces a single pass through the switch
statement when p is assigned to cur_line.

This change eliminates the segmentation faults I was experiencing with
my C code, but I have no understanding of whether it makes sense in the
larger context of how indent works.

Hope this helps!

Cheers,
Warren

int current_column (void)
{
char *p;
int column;
int once = false;
/* Use save_com.size here instead of save_com.end, because save_com
is
* already emptied at this point. */

if ((buf_ptr >= save_com.ptr) && (buf_ptr <= save_com.ptr +
save_com.len))
{
p = save_com.ptr;
column = save_com.start_column;
}
else
{
p = cur_line;
column = 1;
once = true;
}

while (p < buf_ptr)
{
switch (*p)
{
case EOL:
case 014: /* form feed */
column = 1;
break;

case TAB:
column += settings.tabsize - (column - 1) %
settings.tabsize;
break;

case '\b': /* backspace */
column--;
break;

default:
column++;
break;
}
if(once)
break;
p++;
}
return column;
}

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re-indent only??

2009-06-10T12:19:33Z

Is there a way to make indent only do a re-indentation of the file and not make style changes?
I don't want it to move any braces to a new line, or make any other style changes, but I would like indentation errors to be re-aligned correctly.

I've gone through all the different options and can't find anything that works.

Re: Segfault on Comment Line

2009-06-07T04:20:50Z

Nope, no crash for me with r65 either.

David.

Neil Tiffin wrote:

> Ok, a couple of things.
>
> 1. Depending on when you checked the source file you may have used the
> wrong version. After submitting the bug report, I updated the source
> file from r65 to r99. The original problem version is now here:
>
> http://code.google.com/p/rpostgresql/source/browse/trunk/RPostgreSQL/src/RS-PostgreSQL.c?r=65
>
>
> svn export -r 65
> http://rpostgresql.googlecode.com/svn/trunk/RPostgreSQL/src/RS-PostgreSQL.c
>
>
> 2. I fixed the problem by running the source through astyle
> (http://sourceforge.net/projects/astyle) using the command "astyle
> --brackets=attach --verbose RS-PostgreSQL.c" then through indent.
> After being processed by astyle indent did not give any error. You
> can diff the two files to see the changes.
>
> 3. Yes the line "completed = -1;" is ambiguous in the source.
> Either astyle or indent changed it. The compiler never complained. I
> am in the process of verifying the correct operation with unit tests.
>
> 4. I just verified again that checking out the code via the above svn
> command still has the same SEGFAULT problem. It may be a line ending
> problem since svn changes depending on the operating system being
> used. If you want I can send the exact file as it exists on my system.
>
> 5. The warnings at line 139 appear to be where a single line "if"
> statement is broken into two lines. There are no comments in the
> vicinity of line 139.
>
> 6. running indent with no options on the original problem file seems
> to work fine. Only reporting the following warnings.
> indent: RS-PostgreSQL.c:597: Warning:old style assignment
> ambiguity in "=-". Assuming "= -"
>
> indent: RS-PostgreSQL.c:1118: Warning:old style assignment
> ambiguity in "=-". Assuming "= -"
>
> 7. I verified the problem exists with both GNU indent 2.2.9 and GNU
> indent 2.2.10.
>
> Neil
>
> On May 21, 2009, at 3:51 AM, indent wrote:
>
>> I cannot reproduce the problem with indent 2.2.10 using x64 Suse.
>>
>> Here is my terminal output:
>>
>> *> indent --verbose -br -i4 -nut --line-length120
>> --comment-line-length120 --leave-preprocessor-space -npcs
>> RS-PostgreSQL.c*
>> option: br
>> option: i
>> option: nut
>> option: l
>> option: lc
>> option: lps
>> option: npcs
>> There were 1301 non-blank output lines and 274 comments
>> (Lines with comments)/(Lines with code): 0.248
>> *> indent --version*
>> GNU indent 2.2.10
>>
>> I suggest you look in the input source file UP TO line 139 where you
>> first get a warning - probably a missing comment close. The warning
>> about line 597 does not appear, but I do see the following line at L621:
>>
>> completed = -1;
>>
>> What does your compiler say about the input file?
>>
>> David
>>
>> Neil Tiffin wrote:
>>> indent 2.2.9 and 2.2.10 are both segfaulting on a comment line and in
>>> the same place.
>>>
>>> Below is part of both the resultant file and the source file. The
>>> full source file is at
>>>
>>>
>>> http://code.google.com/p/rpostgresql/source/browse/trunk/RPostgreSQL/src/RS-PostgreSQL.c
>>>
>>>
>>>
>>> When run under debug the following backtrace is produced
>>>
>>> MBP:src nt$ gdb --args /Users/nt/Downloads/indent-2.2.10/src/indent
>>> --verbose -br -i4 -nut --line-length120 --comment-line-length120
>>> --leave-preprocessor-space -npcs RS-PostgreSQL.c
>>> GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40
>>> UTC 2008)
>>> Copyright 2004 Free Software Foundation, Inc.
>>> GDB is free software, covered by the GNU General Public License, and
>>> you are
>>> welcome to change it and/or distribute copies of it under certain
>>> conditions.
>>> Type "show copying" to see the conditions.
>>> There is absolutely no warranty for GDB. Type "show warranty" for
>>> details.
>>> This GDB was configured as "i386-apple-darwin"...Reading symbols for
>>> shared libraries .... done
>>>
>>> (gdb) r
>>> Starting program: /Users/neiltiffin/Downloads/indent-2.2.10/src/indent
>>> --verbose -br -i4 -nut --line-length120 --comment-line-length120
>>> --leave-preprocessor-space -npcs RS-PostgreSQL.c
>>> Reading symbols for shared libraries +++. done
>>> option: br
>>> option: i
>>> option: nut
>>> option: l
>>> option: lc
>>> option: lps
>>> option: npcs
>>> indent: RS-PostgreSQL.c:139: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:140: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:141: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:142: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:143: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:144: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:145: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:184: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:185: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:186: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:187: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:188: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:189: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:190: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:360: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:432: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:438: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:597: Warning:old style assignment ambiguity in
>>> "=-". Assuming "= -"
>>>
>>> indent: RS-PostgreSQL.c:618: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:620: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:639: Warning:Line broken 2
>>> indent: RS-PostgreSQL.c:674: Warning:Line broken 2
>>>
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_INVALID_ADDRESS at address: 0x0002d000
>>> current_column () at code_io.c:204
>>> 204 switch (*p)
>>> (gdb) bt
>>> #0 current_column () at code_io.c:204
>>> #1 0x00008158 in print_comment (paren_targ=0x15014,
>>> pbreak_line=0xbffff09c "") at comments.c:273
>>> #2 0x000064a6 in indent (this_file=<value temporarily unavailable,
>>> due to optimizations>) at indent.c:2908
>>> #3 0x00006eab in main (argc=10, argv=0xbffff1bc) at indent.c:3242
>>> (gdb)
>>>
>>> I suspect something in the source is causing this. How do I
>>> troubleshoot to find out? The particular source line looks benign. I
>>> have checked for goofy characters in the source and there are none.
>>>
>>> Neil
>>>
>>> the result file ends here.
>>> ==============================================================
>>> #define BEGIN_GROUP 4 /* just read in 1'st row for a
>>> different group */
>>> #define END_GROUP 8 /* just read the last row of the
>>> current group */
>>> #define NEW_RECORD 16 /* unin
>>>
>>>
>>> the partial source file is
>>> ==============================================================
>>> s_object *expand_list(s_object *old, Sint new_len);
>>> void add_group(s_object *group_names, s_object *data,
>>> Stype *fld_Sclass, Sint group,
>>> Sint ngroup, Sint i);
>>> unsigned int check_groupEvents(s_object *data, Stype fld_Sclass[],
>>> Sint row, Sint col);
>>>
>>> /* The following are the masks for the events/states we recognize as we
>>> * bring rows from the result set/cursor
>>> */
>>> #define NEVER 0
>>> #define BEGIN 1 /* prior to reading 1st row from the
>>> resultset */
>>> #define END 2 /* after reading last row from the result
>>> set */
>>> #define BEGIN_GROUP 4 /* just read in 1'st row for a different
>>> group */
>>> #define END_GROUP 8 /* just read the last row of the current
>>> group */
>>> #define NEW_RECORD 16 /* uninteresting */
>>> #define PARTIAL_GROUP 32 /* too much data (>max_rex) partial
>>> buffer */
>>>
>>> /* the following are non-grouping events (e.g., db errors, memory) */
>>> #define EXHAUSTED_DF 64 /* exhausted the allocated data.frame */
>>> #define EXHAUSTED_OUT 128 /* exhausted the allocated output list */
>>> #define END_OF_DATA 256 /* end of data from the result set */
>>> #define DBMS_ERROR 512 /* error in remote dbms */
>>>
>>> /* beginGroupFun takes only one arg: the name of the current group */
>>> s_object *
>>> RS_DBI_invokeBeginGroup(s_object *callObj, /* should be
>>> initialized */
>>> const char *group_name, /* one string */
>>> s_object *rho)
>>> {
>>> S_EVALUATOR
>>>
>>> s_object *s_group_name, *val;
>>>
>>> /* make a copy of the argument */
>>> MEM_PROTECT(s_group_name = NEW_CHARACTER((Sint) 1));
>>> SET_CHR_EL(s_group_name, 0, C_S_CPY(group_name));
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> bug-indent mailing list
>>> bug-indent@...
>>> http://lists.gnu.org/mailman/listinfo/bug-indent
>>>
>>
>
>

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re: indent enhancement request remove unneeded brackets

2009-05-26T07:31:44Z

On Fri, May 22, 2009 at 11:48 AM, w langdon
<william.bill.langdon@...> wrote:
> I do not know how easy it would be to do this, but one of our users
> has requested that indent be able to remove unnecessary "{" "}".
>
> Some automatically generated C (produced by CIL) has many
> extra brackets, which serve only to clutter the source code
> and it would be nice if gnu indent could remove them from its
> pretty print.

Hi Bill,

Uncrustify can remove unnecessary braces. It can also add them.
http://uncrustify.sourceforge.net/

Ben

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re: indent enhancement request remove unneeded brackets

2009-05-25T12:20:55Z

w langdon wrote:

> I do not know how easy it would be to do this, but one of our users
> has requested that indent be able to remove unnecessary "{" "}".
>
> Some automatically generated C (produced by CIL) has many
> extra brackets, which serve only to clutter the source code
> and it would be nice if gnu indent could remove them from its
> pretty print.
>
> Thank you
>
> Bill
>
> Dr. W. B. Langdon,
> Department of Computer Science,
> King's College London,
> Strand, London, WC2R 2LS, UK
> http://www.cs.ucl.ac.uk/external/W.Langdon
>
> A Field Guide to Genetic Programming
> http://www.gp-field-guide.org.uk/
> Evolving purple robot
> http://bioinformatics.essex.ac.uk/users/wlangdon/field_guide/
> CIGPU 2009 http://www.cs.ucl.ac.uk/external/W.Langdon/cigpu
> GP EM http://www.springer.com/10710
> GP Bibliography http://www.cs.bham.ac.uk/~wbl/biblio/
>
>
> _______________________________________________
> bug-indent mailing list
> bug-indent@...
> http://lists.gnu.org/mailman/listinfo/bug-indent
>
>

Bill,
Thank you for your suggestion. In my opinion, however, it is beyond the
scope of indent to modify syntactic elements of the source code. The
purpose of indent is to adjust the white space between the syntactic
elements. It would be better to fix the problem at the origin by
adapting CIL to not produce superfluous braces.

David.

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

indent enhancement request remove unneeded brackets

2009-05-22T09:48:54Z

I do not know how easy it would be to do this, but one of our users
has requested that indent be able to remove unnecessary "{" "}".

Some automatically generated C (produced by CIL) has many
extra brackets, which serve only to clutter the source code
and it would be nice if gnu indent could remove them from its
pretty print.

Thank you

Bill

Dr. W. B. Langdon,
Department of Computer Science,
King's College London,
Strand, London, WC2R 2LS, UK
http://www.cs.ucl.ac.uk/external/W.Langdon

A Field Guide to Genetic Programming
http://www.gp-field-guide.org.uk/
Evolving purple robot
http://bioinformatics.essex.ac.uk/users/wlangdon/field_guide/
CIGPU 2009 http://www.cs.ucl.ac.uk/external/W.Langdon/cigpu
GP EM http://www.springer.com/10710
GP Bibliography http://www.cs.bham.ac.uk/~wbl/biblio/

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent

Re: Segfault on Comment Line

2009-05-21T05:47:30Z

Ok, a couple of things.

1. Depending on when you checked the source file you may have used the
wrong version. After submitting the bug report, I updated the source
file from r65 to r99. The original problem version is now here:

http://code.google.com/p/rpostgresql/source/browse/trunk/RPostgreSQL/src/RS-PostgreSQL.c?r=65

svn export -r 65 http://rpostgresql.googlecode.com/svn/trunk/RPostgreSQL/src/RS-PostgreSQL.c

2. I fixed the problem by running the source through astyle (http://sourceforge.net/projects/astyle
) using the command "astyle --brackets=attach --verbose RS-
PostgreSQL.c" then through indent. After being processed by astyle
indent did not give any error. You can diff the two files to see the
changes.

3. Yes the line "completed = -1;" is ambiguous in the source.
Either astyle or indent changed it. The compiler never complained. I
am in the process of verifying the correct operation with unit tests.

4. I just verified again that checking out the code via the above svn
command still has the same SEGFAULT problem. It may be a line ending
problem since svn changes depending on the operating system being
used. If you want I can send the exact file as it exists on my system.

5. The warnings at line 139 appear to be where a single line "if"
statement is broken into two lines. There are no comments in the
vicinity of line 139.

6. running indent with no options on the original problem file seems
to work fine. Only reporting the following warnings.
indent: RS-PostgreSQL.c:597: Warning:old style assignment ambiguity
in "=-". Assuming "= -"

indent: RS-PostgreSQL.c:1118: Warning:old style assignment ambiguity
in "=-". Assuming "= -"

7. I verified the problem exists with both GNU indent 2.2.9 and GNU
indent 2.2.10.

Neil

On May 21, 2009, at 3:51 AM, indent wrote:

> I cannot reproduce the problem with indent 2.2.10 using x64 Suse.
>
> Here is my terminal output:
>
> *> indent --verbose -br -i4 -nut --line-length120
> --comment-line-length120 --leave-preprocessor-space -npcs RS-
> PostgreSQL.c*
> option: br
> option: i
> option: nut
> option: l
> option: lc
> option: lps
> option: npcs
> There were 1301 non-blank output lines and 274 comments
> (Lines with comments)/(Lines with code): 0.248
> *> indent --version*
> GNU indent 2.2.10
>
> I suggest you look in the input source file UP TO line 139 where you
> first get a warning - probably a missing comment close. The warning
> about line 597 does not appear, but I do see the following line at
> L621:
>
> completed = -1;
>
> What does your compiler say about the input file?
>
> David
>
> Neil Tiffin wrote:
>> indent 2.2.9 and 2.2.10 are both segfaulting on a comment line and in
>> the same place.
>>
>> Below is part of both the resultant file and the source file. The
>> full source file is at
>>
>> http://code.google.com/p/rpostgresql/source/browse/trunk/RPostgreSQL/src/RS-PostgreSQL.c
>>
>>
>> When run under debug the following backtrace is produced
>>
>> MBP:src nt$ gdb --args /Users/nt/Downloads/indent-2.2.10/src/indent
>> --verbose -br -i4 -nut --line-length120 --comment-line-length120
>> --leave-preprocessor-space -npcs RS-PostgreSQL.c
>> GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40
>> UTC 2008)
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and
>> you are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for
>> details.
>> This GDB was configured as "i386-apple-darwin"...Reading symbols for
>> shared libraries .... done
>>
>> (gdb) r
>> Starting program: /Users/neiltiffin/Downloads/indent-2.2.10/src/
>> indent
>> --verbose -br -i4 -nut --line-length120 --comment-line-length120
>> --leave-preprocessor-space -npcs RS-PostgreSQL.c
>> Reading symbols for shared libraries +++. done
>> option: br
>> option: i
>> option: nut
>> option: l
>> option: lc
>> option: lps
>> option: npcs
>> indent: RS-PostgreSQL.c:139: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:140: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:141: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:142: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:143: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:144: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:145: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:184: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:185: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:186: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:187: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:188: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:189: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:190: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:360: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:432: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:438: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:597: Warning:old style assignment ambiguity
>> in
>> "=-". Assuming "= -"
>>
>> indent: RS-PostgreSQL.c:618: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:620: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:639: Warning:Line broken 2
>> indent: RS-PostgreSQL.c:674: Warning:Line broken 2
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x0002d000
>> current_column () at code_io.c:204
>> 204 switch (*p)
>> (gdb) bt
>> #0 current_column () at code_io.c:204
>> #1 0x00008158 in print_comment (paren_targ=0x15014,
>> pbreak_line=0xbffff09c "") at comments.c:273
>> #2 0x000064a6 in indent (this_file=<value temporarily unavailable,
>> due to optimizations>) at indent.c:2908
>> #3 0x00006eab in main (argc=10, argv=0xbffff1bc) at indent.c:3242
>> (gdb)
>>
>> I suspect something in the source is causing this. How do I
>> troubleshoot to find out? The particular source line looks benign. I
>> have checked for goofy characters in the source and there are none.
>>
>> Neil
>>
>> the result file ends here.
>> ==============================================================
>> #define BEGIN_GROUP 4 /* just read in 1'st row for a
>> different group */
>> #define END_GROUP 8 /* just read the last row of the
>> current group */
>> #define NEW_RECORD 16 /* unin
>>
>>
>> the partial source file is
>> ==============================================================
>> s_object *expand_list(s_object *old, Sint new_len);
>> void add_group(s_object *group_names, s_object *data,
>> Stype *fld_Sclass, Sint group,
>> Sint ngroup, Sint i);
>> unsigned int check_groupEvents(s_object *data, Stype fld_Sclass[],
>> Sint row, Sint col);
>>
>> /* The following are the masks for the events/states we recognize
>> as we
>> * bring rows from the result set/cursor
>> */
>> #define NEVER 0
>> #define BEGIN 1 /* prior to reading 1st row from the
>> resultset */
>> #define END 2 /* after reading last row from the result
>> set */
>> #define BEGIN_GROUP 4 /* just read in 1'st row for a different
>> group */
>> #define END_GROUP 8 /* just read the last row of the current
>> group */
>> #define NEW_RECORD 16 /* uninteresting */
>> #define PARTIAL_GROUP 32 /* too much data (>max_rex) partial
>> buffer */
>>
>> /* the following are non-grouping events (e.g., db errors, memory) */
>> #define EXHAUSTED_DF 64 /* exhausted the allocated data.frame */
>> #define EXHAUSTED_OUT 128 /* exhausted the allocated output list */
>> #define END_OF_DATA 256 /* end of data from the result set */
>> #define DBMS_ERROR 512 /* error in remote dbms */
>>
>> /* beginGroupFun takes only one arg: the name of the current group */
>> s_object *
>> RS_DBI_invokeBeginGroup(s_object *callObj, /* should be
>> initialized */
>> const char *group_name, /* one string */
>> s_object *rho)
>> {
>> S_EVALUATOR
>>
>> s_object *s_group_name, *val;
>>
>> /* make a copy of the argument */
>> MEM_PROTECT(s_group_name = NEW_CHARACTER((Sint) 1));
>> SET_CHR_EL(s_group_name, 0, C_S_CPY(group_name));
>>
>>
>>
>>
>> _______________________________________________
>> bug-indent mailing list
>> bug-indent@...
>> http://lists.gnu.org/mailman/listinfo/bug-indent
>>
>

_______________________________________________
bug-indent mailing list
bug-indent@...
http://lists.gnu.org/mailman/listinfo/bug-indent