perlapi: s/encapsulated argument list/va_list/g

deb.c

@@ -57,7 +57,7 @@ C<deb> and C<deb_nocontext> differ only in that C<deb_nocontext> does not take
 a thread context (C<aTHX>) parameter, so is used in situations where the caller
 doesn't already have the thread context.
 
-C<vdeb> is the same as C<deb> except C<args> are an encapsulated argument list.
+C<vdeb> is the same as C<deb> except C<args> is a pointer to a C<va_list>.
 
 =cut
 */

op.c

@@ -8504,7 +8504,7 @@ So use the latter when you get a compilation error about C<pTHX>.
 =for apidoc Amnh||PERL_LOADMOD_IMPORT_OPS
 
 =for apidoc vload_module
-Like C<L</load_module>> but the arguments are an encapsulated argument list.
+Like C<L</load_module>> but the arguments are a C<va_list>.
 
 =cut */
 

sv.c

@@ -10439,7 +10439,7 @@ so is used in situations where the caller doesn't already have the thread
 context.
 
 =for apidoc vnewSVpvf
-Like C<L</newSVpvf>> but the arguments are an encapsulated argument list.
+Like C<L</newSVpvf>> but the arguments are a C<va_list>.
 
 =cut
 */
@@ -11600,7 +11600,7 @@ eventually calling it.  It does not handle magic; the forms whose name contains
 C<_mg> additionally handle 'set' magic after calling it.
 
 It has two sets of argument lists, only one of which is used in any given call.
-The first set, C<args>, is an encapsulated argument list of pointers to C
+The first set, C<args>, is a pointer to a C<va_list> of pointers to C
 strings.  If it is NULL, the other list, C<svargs>, is used; it is an array
 of pointers to SV's.  C<sv_count> gives how many there are in the list.
 
@@ -11633,7 +11633,7 @@ The forms whose name contains C<_no_context> do not take a thread
 context (C<aTHX>) parameter, so are used in situations where the caller
 doesn't already have the thread context.
 
-The forms whose name contains C<vset> use an encapsulated argument list, the
+The forms whose name contains C<vset> use a C<va_list>, the
 other forms use C<sprintf>-style arguments.
 
 There are no other differences between the forms.
@@ -11749,7 +11749,7 @@ C<sv_vcatpvfn_flags> is the most general, and all the other forms are
 implemented by eventually calling it.
 
 It has two sets of argument lists, only one of which is used in any given call.
-The first set, C<args>, is an encapsulated argument list of pointers to C
+The first set, C<args>, is a pointer to a C<va_list> of pointers to C
 strings.  If it is NULL, the other list, C<svargs>, is used; it is an array
 of pointers to SV's.  C<sv_count> gives how many there are in the list.
 
@@ -11792,7 +11792,7 @@ The forms whose name contains C<_no_context> do not take a thread
 context (C<aTHX>) parameter, so are used in situations where the caller
 doesn't already have the thread context.
 
-The forms whose name contains C<vcat> use an encapsulated argument list, the
+The forms whose name contains C<vcat> use a C<va_list>, the
 other forms use C<sprintf>-style arguments.
 
 There are no other differences between the forms.

util.c

@@ -1439,8 +1439,8 @@ not take a thread context (C<aTHX>) parameter, so is used in situations where
 the caller doesn't already have the thread context (and can be called without
 the C<Perl_> prefix.
 
-C<vform> is the same as C<form> except the arguments are an encapsulated
-argument list.  It does need a thread context parameter, but that is supplied
+C<vform> is the same as C<form> except the arguments are a C<va_list>.
+It does need a thread context parameter, but that is supplied
 automatically when called without the C<Perl_> prefix.
 
 =cut
@@ -1481,8 +1481,8 @@ C<mess> and C<mess_nocontext> differ only in that C<mess_nocontext> does
 not take a thread context (C<aTHX>) parameter, so is used in situations where
 the caller doesn't already have the thread context.
 
-C<vmess> is the same as C<mess> except the arguments are an encapsulated
-argument list.  It needs a thread context parameter only when called with the
+C<vmess> is the same as C<mess> except the arguments are a <va_list>.
+It needs a thread context parameter only when called with the
 C<Perl_> prefix.
 
 Normally, the resulting message is returned in a new mortal SV.