On Sun, Aug 21, 2022 at 12:23:21AM +0200, Omar Polo wrote:
> On 2022/08/20 22:15:51 +0200, Stefan Sperling <stsp@stsp.name> wrote:
> > On Sat, Aug 20, 2022 at 05:08:36PM +0200, Omar Polo wrote:
> > > I had an issue with it: gotwebd binds the wrong port.  I think there's
> > > an extra `htons' in the fcgiport rule.  with that dropped, i can
> > > happily have gotwebd listen on localhost:9000.
> > 
> > Ah, thanks. I will take a look.
> 
> As far as i can see we're storing the port number in hots byte order,
> in fact getservice does ntohs on the port returned by getservbyname
> (which is in network byte order) and then we convert them to network
> byte order in sockets_create_socket.
> 
> however, the NUMBER part of the fcgiport grammar rule parse the number
> and converts it to network byte order.  the we will convert it again
> to network byte order in sockets_create_socket...
> 
> > > @@ -159,7 +159,7 @@ fcgiport	: NUMBER {
> > >  				yyerror("invalid port: %lld", $1);
> > >  				YYERROR;
> > >  			}
> > > -			$$ = htons($1);
> > > +			$$ = $1;

ok stsp@

Yeah. Let's not do byte-swaps in a config file parser...

Byte-swapping this number for use such as writing it to the debug
log is awkward. I prefer to store it in native order for easy direct
use, and swap bytes once the variable gets copied to a data structure
which does actually require network byte order. That also makes it
more obvious why swapping is required and where.

> > >  		}
> > >  		| STRING {
> > >  			int	 val;
> 
> 
>