rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: Christopher.Vance@adfa.oz.au (Christopher JS Vance)
To: rc@hawkwind.utcs.toronto.edu
Subject: Re: difference between <varargs.h> and <stdarg.h> ?
Date: Thu, 15 Apr 1993 00:33:53 -0400	[thread overview]
Message-ID: <199304150433.AA11980@ccadfa.cc.adfa.oz.au> (raw)
In-Reply-To: <1993Apr15.042726.22102@sserve.cc.adfa.oz.au>

In article <1993Apr14.163211.4342@thunder.mcrcim.mcgill.edu> in
newsgroup comp.lang.c talking about <stdarg.h> and <varargs.h>
mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:

| On systems where both exist, they are normally compatible, in that you
| can use an ANSI prototype to call a function written to use
| <varargs.h>, and you can write a function using <stdarg.h> and then
| call it as a varargs function from traditional code.  No guarantees, of
| course, but when both headers exist this will usually work.

I found, when porting Byron Rakitzis' implementation of rc to a
Pyramid 9810 running OSx 5.1, that I had a purported ANSI-compatible
compiler (grokking prototypes and const), but no <stdarg.h>.  (Pyramid
have shipped <varargs.h> for years, and it's a bit strange...)

This rc uses prototyped functions throughout, using new-style for both
declarations and definitions.

What worked for me was to remove the argument prototypes (just from
the variadic functions) leaving the return type and empty parentheses.
For the definition, the Pyramid <varargs.h> allows it to include the
va_alist *after* some fixed arguments (if there were fixed arguments,
they had to be declared old-style with only the argument names inside
the parentheses).  And I had to change the invocations of va_start in
the routine bodies to omit the second parameter.

I guess I could have hacked the definitions even more to put the
va_alist in as the only argument, but this was the only architecture I
had which didn't do <stdarg.h> properly, and my way meant minimal
change to the bodies of these routines.

I also toyed with trying to make a <stdarg.h> that did the right
thing, but I knew that <varargs.h> worked, so it was easier to do this
workaround.  (And when I looked at gcc's way I felt sick.  I still
haven't the time or heart to try to get gcc doing things the right way
on the Pyramid.)

-- Christopher


           reply	other threads:[~1993-04-15  4:34 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <1993Apr15.042726.22102@sserve.cc.adfa.oz.au>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199304150433.AA11980@ccadfa.cc.adfa.oz.au \
    --to=christopher.vance@adfa.oz.au \
    --cc=rc@hawkwind.utcs.toronto.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).