www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - vsprintf or printf variable arguments

reply Mark "J" Twain <Juckleberry Twain.com> writes:
How can I construct a va_list for vsprintf when all I have is the 
a list of pointers to the data, without their type info?

A va_list seems to be a packed struct of values and/or pointers 
to the data. While I could construct such a list, theoretically, 
I don't always know when I should store an element as a pointer 
or a value.

e.g., ints, floats, and other value types seems to get stored 
directly in the list, while strings and *other* stuff get stored 
as pointers.

I would be nice if a printf variant listed takes only a pointer 
list to all the values, does anything like this exist?

If not, is there any standardization of what is a value in the 
list and what is a pointer so I can attempt to build the list 
properly?
Aug 04 2016
next sibling parent Mark "J" Twain <Juckleberry Twain.com> writes:
On Thursday, 4 August 2016 at 21:03:52 UTC, Mark "J" Twain wrote:

 How can I construct a va_list for vsprintf when all I have is 
 the a list of pointers to the data, without their type info?

 A va_list seems to be a packed struct of values and/or pointers 
 to the data. While I could construct such a list, 
 theoretically, I don't always know when I should store an 
 element as a pointer or a value.

 e.g., ints, floats, and other value types seems to get stored 
 directly in the list, while strings and *other* stuff get 
 stored as pointers.

 I would be nice if a printf variant listed takes only a pointer 
 list to all the values, does anything like this exist?

 If not, is there any standardization of what is a value in the 
 list and what is a pointer so I can attempt to build the list 
 properly?


What I have done is built up the data serially, storing pointers 
for strings and otherwise copying the data. It works, a little 
messy, but works.
Aug 04 2016
prev sibling parent reply kink <noone nowhere.com> writes:
On Thursday, 4 August 2016 at 21:03:52 UTC, Mark "J" Twain wrote:

 How can I construct a va_list for vsprintf when all I have is 
 the a list of pointers to the data, without their type info?

 A va_list seems to be a packed struct of values and/or pointers 
 to the data. While I could construct such a list, 
 theoretically, I don't always know when I should store an 
 element as a pointer or a value.

 e.g., ints, floats, and other value types seems to get stored 
 directly in the list, while strings and *other* stuff get 
 stored as pointers.

 I would be nice if a printf variant listed takes only a pointer 
 list to all the values, does anything like this exist?

 If not, is there any standardization of what is a value in the 
 list and what is a pointer so I can attempt to build the list 
 properly?


This has absolutely nothing to do with D as these are C 
functions, so you'd be better off asking this in another forum. 
Anyway, I have no idea why you'd want to construct the va_list 
manually. These vprintf() functions only exist so that other 
variadic functions can forward THEIR varargs - e.g.,

extern(C) void myOldschoolPrintf(in char* format, ...)
{
   doSomethingSpecial();
   va_list myVarargs = va_start(format);
   vprintf(format, myVarargs);
}

Note that va_list is highly platform-dependent, so filling the 
struct manually is a very bad idea.
Aug 05 2016
next sibling parent reply Mark "J" Twain <Juckleberry Twain.com> writes:
On Friday, 5 August 2016 at 08:32:42 UTC, kink wrote:

 On Thursday, 4 August 2016 at 21:03:52 UTC, Mark "J" Twain [...]

 This has absolutely nothing to do with D as these are C 
 functions, so you'd be better off asking this in another forum.


Um, then I wonder why I am using D? Why does D even have C stuff 
in it if it has ABSOLUTELY nothing to do with D?


 Anyway, I have no idea why you'd want to construct the va_list 
 manually.


Of course you don't, do you have ESP? Do you need to see a 
psychologist?


 These vprintf() functions only exist so that other variadic 
 functions can forward THEIR varargs - e.g.,

 extern(C) void myOldschoolPrintf(in char* format, ...)
 {
   doSomethingSpecial();
   va_list myVarargs = va_start(format);
   vprintf(format, myVarargs);
 }

 Note that va_list is highly platform-dependent, so filling the 
 struct manually is a very bad idea.


So? People do bad stuff all the time, you should know a lot about 
that? Or are you Jesus?

Ok, thanks for the help. I appreciate it! I know absolutely 
nothing more than I did about the problem I asked. At least my 
reply to my self works and accomplishes the task I posted about 
in the first place.
Aug 05 2016
parent flamencofantasy <flamencofantasy gmail.com> writes:
On Friday, 5 August 2016 at 19:21:38 UTC, Mark "J" Twain wrote:

 On Friday, 5 August 2016 at 08:32:42 UTC, kink wrote:

 On Thursday, 4 August 2016 at 21:03:52 UTC, Mark "J" Twain 
 [...]

 This has absolutely nothing to do with D as these are C 
 functions, so you'd be better off asking this in another forum.


 Um, then I wonder why I am using D? Why does D even have C 
 stuff in it if it has ABSOLUTELY nothing to do with D?


 Anyway, I have no idea why you'd want to construct the va_list 
 manually.


 Of course you don't, do you have ESP? Do you need to see a 
 psychologist?


 These vprintf() functions only exist so that other variadic 
 functions can forward THEIR varargs - e.g.,

 extern(C) void myOldschoolPrintf(in char* format, ...)
 {
   doSomethingSpecial();
   va_list myVarargs = va_start(format);
   vprintf(format, myVarargs);
 }

 Note that va_list is highly platform-dependent, so filling the 
 struct manually is a very bad idea.


 So? People do bad stuff all the time, you should know a lot 
 about that? Or are you Jesus?

 Ok, thanks for the help. I appreciate it! I know absolutely 
 nothing more than I did about the problem I asked. At least my 
 reply to my self works and accomplishes the task I posted about 
 in the first place.



Could you please stop changing your alias from;
Joerg Joergonson to Hiemlick Hiemlicker to Adam Sansier to Rufus 
Smith to Mark "J" Twain so that those who don't want to read you 
can filter you out once and for all.
Just pick one and stick with it!
Thanks!
Aug 05 2016
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 5 August 2016 at 08:32:42 UTC, kink wrote:

 On Thursday, 4 August 2016 at 21:03:52 UTC, Mark "J" Twain 
 wrote:

 How can I construct a va_list for vsprintf when all I have is 
 the a list of pointers to the data, without their type info?

 A va_list seems to be a packed struct of values and/or 
 pointers to the data. While I could construct such a list, 
 theoretically, I don't always know when I should store an 
 element as a pointer or a value.

 e.g., ints, floats, and other value types seems to get stored 
 directly in the list, while strings and *other* stuff get 
 stored as pointers.

 I would be nice if a printf variant listed takes only a 
 pointer list to all the values, does anything like this exist?

 If not, is there any standardization of what is a value in the 
 list and what is a pointer so I can attempt to build the list 
 properly?


 This has absolutely nothing to do with D as these are C 
 functions, so you'd be better off asking this in another forum. 
 Anyway, I have no idea why you'd want to construct the va_list 
 manually. These vprintf() functions only exist so that other 
 variadic functions can forward THEIR varargs - e.g.,

 extern(C) void myOldschoolPrintf(in char* format, ...)
 {
   doSomethingSpecial();
   va_list myVarargs = va_start(format);
   vprintf(format, myVarargs);
 }


Just a side note, a C nitpicker that I am, you forgot the va_end 
after the call to vprintf(). On a lot of platforms it's not a 
problem, on Linux/x86_64 (i.e. a very common platform) it's very 
likely a memory leak (as the ABI allows to pass parameters in 
register even for vararg functions, these registers have to be 
saved somewhere to be usable in a va_list).

 Note that va_list is highly platform-dependent, so filling the 
 struct manually is a very bad idea.


Yes indeed, and one of the most common platforms is the very 
complex one. It's probably the most common issue when porting C 
programs to Linux/x86_64 for the first time.
Aug 06 2016