MIPS varargs (Was Re: Reality check)

[Ron Guilmette]

In article <14322 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>In article <108077 at convex.convex.com> gargulak at mozart.convex.com (Tom Gargulak) writes:
>>For example, the following two functions will have different codegen.
>>	test(Xa_alist) {}
>>	test(va_alist) {}
>>No include files required.
>
>Well, that's clearly wrong behavior, since both these are merely functions
>having a single int-valued parameter.

I think that it's wrong to say that that's wrong behavior.

What's wrong with it?

Are you assuming that the generated code not only is different, but also
that the differences are detectable (other than simply speed differences)?

He didn't say that the *different* code voilated any ANSI requirement
for run-time behavior.

If a va_list falls in the forest, and there is nobody there to hear it,
does this violate ANSI rules? :-)

I happen to be attuned to this issue because I've been implementing
support for AT&T's new debug format (DWARF) in GCC.

In order to generate *proper* debugging information, I have to check
each function to see if its first parameter has a particular *special*
name (which will indicate that it is an old-style varargs function).

Now, does the fact that I generate different debugging information for
functions whose first parameter is named `foobar' make the compiler
that I'm working on non-standard?  I doubt it.

Would that fact that a given compiler generated different executable
code for functions whose first parameter was named `foobar' in and
of itself make that compiler non-standard.  I don't think so.

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg at ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.