Use of va_start in URLUtils

While trying to compile BatchOne C components with GCC C I came across something that GCC objects to. Networking.CheckURL.c.URLutils uses va_start in a way wbich I think is distinctly non-ANSI.

The va_list system is to be used to access the trailing variable parameters in a function defined as eg fn(parm1, parm2, ...). Then va_start(list, parm2) moves the variable set of parameters following parm2 into the va_list list. This is as defined in the Acorn/Castle C/C++ manual (including the on-disc updated version), and in the ANSI C manual I have.

Is this an undocumented extension in the Acorn/Castle C compiler? (Or in the Norcroft C original?) What does it do? Does url_d contain something that looks like a series of parameters? Or is it actually url_s that is being accessed?

Actually, looking closer at the specific code reveals even stranger things. The purpose of the whole function is to translate url_s into the more accessible url_d. The result isn’t copied into url_d until the end of the function. Thus when va_start is used, url_d’s contents are undefined. On top of that the only use made of the va_list system is to give a value to _kernel_oserror ** re. But then re doesn’t contribute to the rest of the function, so the whole va_ bit seems disposable.

If my analysis is correct, then I will raise a bug requesting to get rid of the va_ code, and make the component GCC-friendly.

Hope you don’t mind, but I made a small edit to the syntax of your post so the stars in the code snippet wouldn’t get accidentally interpreted by Textile as instructions to put things in bold.

For quick reference, the source in question is visible here:

http://preview.tinyurl.com/2qt2fk

The offending code lies around line 287. Although my name is all over the check-in logs for that, the file actually has a considerably longer history, originally developed outside the CheckURL component. I can’t rule out having written that section myself because this was a long time ago, but I certainly don’t understand what it’s trying to do. It looks like there may be some kind of elaborate use of the varargs macros to essentially cast url_description ** url_d into a _kernel_oserror ** and write NULL to it. Quite why it doesn’t just read “*url_d = NULL” I don’t know. Has a hint of Kevin or Stewart about it ;-) – worth checking the varargs macros carefully to see if there’s anything more altogether cunning going on.