Re: Variable type fix in parse.y (all of them)

2021-10-12 Thread Sebastian Benoit
Christian Weisgerber(na...@mips.inka.de) on 2021.10.12 12:49:24 +0200: > Christian Weisgerber: > > > Here's another attempt, incorporating millert's feedback and adding > > a few more casts: > > Any interest in this or not worth the churn and I should drop it? i think it should go in. ok

Re: Variable type fix in parse.y (all of them)

2021-10-12 Thread Christian Weisgerber
Christian Weisgerber: > Here's another attempt, incorporating millert's feedback and adding > a few more casts: Any interest in this or not worth the churn and I should drop it? > Index: bin/chio/parse.y > === > RCS file:

Re: Variable type fix in parse.y (all of them)

2021-10-02 Thread Christian Weisgerber
Here's another attempt, incorporating millert's feedback and adding a few more casts: Index: bin/chio/parse.y === RCS file: /cvs/src/bin/chio/parse.y,v retrieving revision 1.23 diff -u -p -r1.23 parse.y --- bin/chio/parse.y15 Oct

Re: Variable type fix in parse.y (all of them)

2021-09-30 Thread Todd C . Miller
On Thu, 30 Sep 2021 22:15:39 +0200, Christian Weisgerber wrote: > E.g. like this? Yes, that looks correct. However, this is a bit ugly: if (pushback_index < MAXPUSHBACK-1) return (unsigned char)(pushback_buffer[pushback_index++] = c); else return

Re: Variable type fix in parse.y (all of them)

2021-09-30 Thread Christian Weisgerber
Todd C. Miller: > On Thu, 30 Sep 2021 21:37:06 +0200, Christian Weisgerber wrote: > > > Unfortunately that also affects the parsebuf/pushback_buffer complex > > used in some parser.y files. > > That would require a few extra casts but it is straightforward. E.g. like this? Index:

Re: Variable type fix in parse.y (all of them)

2021-09-30 Thread Todd C . Miller
On Thu, 30 Sep 2021 21:37:06 +0200, Christian Weisgerber wrote: > Unfortunately that also affects the parsebuf/pushback_buffer complex > used in some parser.y files. That would require a few extra casts but it is straightforward. - todd

Re: Variable type fix in parse.y (all of them)

2021-09-30 Thread Christian Weisgerber
Todd C. Miller: > lungetc((u_char)*p); > ... > c = (u_char)*--p; > > Since we use casts sparingly, when they are present they indicate > something you need to pay attention to. That is not the case when > we simply change the type. Unfortunately that also affects the

Re: Variable type fix in parse.y (all of them)

2021-09-30 Thread Todd C . Miller
On Thu, 30 Sep 2021 12:33:58 +0100, Stuart Henderson wrote: > > revision 1.628 > date: 2013/11/25 12:52:45; author: benno; state: Exp; lines: +7 -7; > use u_char for buffers in yylex, for ctype calls > found by millert@, ok deraadt@ >

Re: Variable type fix in parse.y (all of them)

2021-09-30 Thread Stuart Henderson
On 2021/09/29 21:21, Christian Weisgerber wrote: > The oft-copied parse.y code declares some variables as "unsigned char *" > but passes them to functions that take "char *" arguments and doesn't > make any use of the unsigned property. btw, those used to be char:

Re: Variable type fix in parse.y (all of them)

2021-09-30 Thread Christian Weisgerber
Christian Weisgerber: > The oft-copied parse.y code declares some variables as "unsigned char *" > but passes them to functions that take "char *" arguments and doesn't > make any use of the unsigned property. While I'm here... > int > yylex(void) > { > - u_char buf[8096]; > -

Re: Variable type fix in parse.y (all of them)

2021-09-29 Thread Theo de Raadt
OK deraadt

Variable type fix in parse.y (all of them)

2021-09-29 Thread Christian Weisgerber
The oft-copied parse.y code declares some variables as "unsigned char *" but passes them to functions that take "char *" arguments and doesn't make any use of the unsigned property. For OpenBSD's clang, -Wpointer-sign has been disabled by default, but when that code is built elsewhere, the