In my latest patch, I hardcoded the port NUT uses for TCP communication (3493). The reason is, that I can't figure out a way how to change the numeric value of the #define'd PORT into a character string. Using snprintf() and a temporary buffer just seems wrong, since this should be handled by the preprocessor, rather than at runtime. The following files are affected: - server/conf.c (line 205) - server/upsd.c (line 1024) Best regards, Arjen PS I don't want to use a numeric value, since the ports can also be set through their service name (if we use getaddrinfo(), which is neat).
On 1/13/07, Arjen de Korte <nut+devel@de-korte.org> wrote:> In my latest patch, I hardcoded the port NUT uses for TCP communication > (3493). The reason is, that I can't figure out a way how to change the > numeric value of the #define'd PORT into a character string. Using > snprintf() and a temporary buffer just seems wrong, since this should be > handled by the preprocessor, rather than at runtime.I see the 'QUOTED' macro defined in conf.c and upsd.c, but it doesn't look like it is being used. That should work, no? Or is this only permissible in certain versions of the C standard? -- - Charles Lepple
Keep in mind that PORT can be changed at ./configure time (--with-port), so hardcoding it is not an option. There is a way for the proprocessor to convert a number to a string. The syntax is a bit obscure, and I have never seen it used in any actual program. It works like this: #define PORT 3493 #define string_const_aux(x) #x #define string_const(x) string_const_aux(x) char *s = string_const(PORT); Running this through the preprocessor (gcc -E), you get char *s = "3493"; The indirection is needed by the way. If you just do string_const_aux(PORT), you get "PORT" and not "3493". I hope you agree that this is obscure. I think a better solution is to just #define PORT as a character string in the first place. As far as I can see, this primarily affects two lines: include/config.h:197 (i.e. configure.in:505) and clients/upsclient.c:966. The question is when exactly this should be converted to a number. Should this be done in upscli_splitname() or in upscli_connect()? The latter would require a change in the prototypes of upscli_splitname() and upscli_connect(), and an attendant change in all the existing clients. When changing the "port" argument to a string, the API should also define whether this is allocated (and must be freed) or not. Alternatively, perhaps it is better to convert any symbolic value to an integer early, i.e., in upscli_connect(). -- Peter Arjen de Korte wrote:> > In my latest patch, I hardcoded the port NUT uses for TCP communication > (3493). The reason is, that I can't figure out a way how to change the > numeric value of the #define'd PORT into a character string. Using > snprintf() and a temporary buffer just seems wrong, since this should be > handled by the preprocessor, rather than at runtime. > > The following files are affected: > - server/conf.c (line 205) > - server/upsd.c (line 1024) > > Best regards, Arjen > > PS I don't want to use a numeric value, since the ports can also be set > through their service name (if we use getaddrinfo(), which is neat). > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev >
selinger wrote:> > Keep in mind that PORT can be changed at ./configure time > (--with-port), so hardcoding it is not an option. > > There is a way for the proprocessor to convert a number to a string. > The syntax is a bit obscure, and I have never seen it used in any > actual program. It works like this: > > #define PORT 3493 > #define string_const_aux(x) #x > #define string_const(x) string_const_aux(x) > > char *s = string_const(PORT); > > Running this through the preprocessor (gcc -E), you get > > char *s = "3493"; > > The indirection is needed by the way. If you just do > string_const_aux(PORT), you get "PORT" and not "3493". I hope you > agree that this is obscure. > > I think a better solution is to just #define PORT as a character > string in the first place. As far as I can see, this primarily affects > two lines: include/config.h:197 (i.e. configure.in:505) and > clients/upsclient.c:966. > > The question is when exactly this should be converted to a number. > Should this be done in upscli_splitname() or in upscli_connect()? The > latter would require a change in the prototypes of upscli_splitname() > and upscli_connect(), and an attendant change in all the existing > clients. When changing the "port" argument to a string, the API should > also define whether this is allocated (and must be freed) or not. > > Alternatively, perhaps it is better to convert any symbolic value to > an integer early, i.e., in upscli_connect().Gah. I meant "early, i.e., in upscli_splitname()".> -- Peter > > Arjen de Korte wrote: > > > > In my latest patch, I hardcoded the port NUT uses for TCP communication > > (3493). The reason is, that I can't figure out a way how to change the > > numeric value of the #define'd PORT into a character string. Using > > snprintf() and a temporary buffer just seems wrong, since this should be > > handled by the preprocessor, rather than at runtime. > > > > The following files are affected: > > - server/conf.c (line 205) > > - server/upsd.c (line 1024) > > > > Best regards, Arjen > > > > PS I don't want to use a numeric value, since the ports can also be set > > through their service name (if we use getaddrinfo(), which is neat). > > > > _______________________________________________ > > Nut-upsdev mailing list > > Nut-upsdev@lists.alioth.debian.org > > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev > > > >