Unix Programming - stdarg help

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > November 2004 > stdarg help





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author stdarg help
Billy N. Patton

2004-11-01, 5:53 pm

I have a c++ method Ui::RequiredEnvVars(char* first,...);

bool Ui::RequiredEnvVars(char* first,...)
{
va_list arg_ptr;
char* var,*env;
int ne = 0;
string s;
va_start(arg_ptr,first);
while (*first)
{
var = va_arg(arg_ptr, char *);
cout << "var : " << var CR;
}
va_end(arg_ptr);
return true;
}

My call :
ui->RequiredEnvVars("PATH","TERM","SHELL");


I know I'm missing the first, I would rather not have to have the first
varaible. But documentation appears to says I need one.
My input will ALYAYS be const char*

I get a result of :
Required environment variables :

var : TERM
var : SHELL
Segmentation fault

ddd shows
(gdb) print var
$1 = 0x10e <Address 0x10e out of bounds>

What am I missing to terminate?

--
___ _ ____ ___ __ __
/ _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
/ _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
/____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
/___/
Texas Instruments ASIC Circuit Design Methodology Group
Dallas, Texas, 214-480-4455, b-patton@ti.com
Paul Pluzhnikov

2004-11-01, 5:53 pm

"Billy N. Patton" <b-patton@ti.com> writes:

> while (*first)


> My call :
> ui->RequiredEnvVars("PATH","TERM","SHELL");


You need to terminate your list, if you expect it to be
NULL-terminated:

ui->RequiredEnvVars("PATH","TERM","SHELL", (char*)0);

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Billy N. Patton

2004-11-01, 5:53 pm

Paul Pluzhnikov wrote:
> "Billy N. Patton" <b-patton@ti.com> writes:
>
>
>
>
>
>
> You need to terminate your list, if you expect it to be
> NULL-terminated:
>
> ui->RequiredEnvVars("PATH","TERM","SHELL", (char*)0);
>
> Cheers,



perfect, THANX

My prior uses of stdarg were alway bades upon a enum as the first arg.
THis told the function what it was supposed to do and exaxtly how many
variables it needed.

--
___ _ ____ ___ __ __
/ _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
/ _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
/____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
/___/
Texas Instruments ASIC Circuit Design Methodology Group
Dallas, Texas, 214-480-4455, b-patton@ti.com
Lőrinczy Zsigmond

2004-11-01, 5:53 pm

Billy N. Patton wrote:
> I have a c++ method Ui::RequiredEnvVars(char* first,...);
>
> bool Ui::RequiredEnvVars(char* first,...)
> {
> va_list arg_ptr;
> char* var,*env;
> int ne = 0;
> string s;
> va_start(arg_ptr,first);

var = first;
while (var)
> {
> cout << "var : " << var CR;

var = va_arg (arg_ptr, char *);
> }
> va_end(arg_ptr);
> return true;
> }
>
> My call :

ui->RequiredEnvVars("PATH","TERM","SHELL",NULL);
Paul Pluzhnikov

2004-11-01, 5:53 pm

=?UTF-8?B?TMWRcmluY3p5IFpzaWdtb25k?= <nospam@for.me> writes:

> ui->RequiredEnvVars("PATH","TERM","SHELL",NULL);


Note that the above is incorrect for C++ compiles, and causes
problems when porting to 64-bit architectures: many C++ compilers
#define NULL to 0 (because C++ prohibts pointer conversion from
void*), and if sizeof(int) != sizeof(char*) you'll have a crash on
e.g. AMD64.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Alex Fraser

2004-11-02, 2:47 am

"Paul Pluzhnikov" <ppluzhnikov-nsp@charter.net> wrote in message
news:m3y8hlw43n.fsf@salmon.parasoft.com...
> =?UTF-8?B?TMWRcmluY3p5IFpzaWdtb25k?= <nospam@for.me> writes:
>
>
> Note that the above is incorrect for C++ compiles,


And C compilers too.

> and causes problems when porting to 64-bit architectures: many C++
> compilers #define NULL to 0


AFAIK, all C++ compilers MUST #define NULL as 0. C compilers may #define
NULL as 0, and some do, although ((void *)0) seems more common.

> and if sizeof(int) != sizeof(char*) you'll have a crash on e.g. AMD64.


Even if sizeof(int) == sizeof(char *), it's not guaranteed to work. (char
*)0 (as you used in your earlier post) and (char *)NULL will always work.

Alex


Paul Pluzhnikov

2004-11-02, 2:47 am

"Alex Fraser" <me@privacy.net> writes:

> AFAIK, all C++ compilers MUST #define NULL as 0.


Well, g++ 3.x uses '__null' which it "knows" to be convertible to
any pointer type; it also "knows" that __null is a pointer, and
warns if you convert it to an integer type.

So MUST is a bit too strong.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Sharad Kala

2004-11-02, 2:47 am


"Paul Pluzhnikov" <ppluzhnikov-nsp@charter.net> wrote in message
> "Alex Fraser" <me@privacy.net> writes:
>
>
> Well, g++ 3.x uses '__null' which it "knows" to be convertible to
> any pointer type; it also "knows" that __null is a pointer, and
> warns if you convert it to an integer type.
>
> So MUST is a bit too strong.


This is what the creator of the language says -
http://www.research.att.com/~bs/bs_faq2.html#null

The point is that in C++ it's NOT ((void *) 0).

Sharad


Alex Fraser

2004-11-02, 2:47 am

"Paul Pluzhnikov" <ppluzhnikov-nsp@charter.net> wrote in message
news:m3is8oafje.fsf@salmon.parasoft.com...
> "Alex Fraser" <me@privacy.net> writes:
>
>
> Well, g++ 3.x uses '__null' which it "knows" to be convertible to
> any pointer type; it also "knows" that __null is a pointer, and
> warns if you convert it to an integer type.
>
> So MUST is a bit too strong.


Not necessarily; g++ could be non-conforming in this respect (not that I
think what you describe is a bad idea). The first few words of the link
Sharad posted agree with what I wrote, but I don't know what the standard
says, which is why I qualified my original comment.

Alex


Sharad Kala

2004-11-02, 7:48 am


"Alex Fraser" <me@privacy.net> wrote in message

> Not necessarily; g++ could be non-conforming in this respect (not that I
> think what you describe is a bad idea). The first few words of the link
> Sharad posted agree with what I wrote, but I don't know what the standard
> says, which is why I qualified my original comment.


The Holy Standard (ISO/IEC 14882:2003) in 18.1/4 says -
"The macro NULL is an implementation-defined C++ null pointer constant in
this International Standard". This line refers to footnote 180 which reads -
"
Possible definitions include 0 and 0L, but not (void*)0."

4.10/1 reads - "A null pointer constant is an integral constant expression
rvalue of integer type that evaluates to zero."

Sharad


Billy N. Patton

2004-11-02, 7:48 am

Paul Pluzhnikov wrote:
> =?UTF-8?B?TMWRcmluY3p5IFpzaWdtb25k?= <nospam@for.me> writes:
>
>
>
>
> Note that the above is incorrect for C++ compiles, and causes
> problems when porting to 64-bit architectures: many C++ compilers
> #define NULL to 0 (because C++ prohibts pointer conversion from
> void*), and if sizeof(int) != sizeof(char*) you'll have a crash on
> e.g. AMD64.
>
> Cheers,


I define NULL as
#define NULL '\0'

Seems to work in both c and c++ for solaris 8 and redhat enterprise

--
___ _ ____ ___ __ __
/ _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
/ _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
/____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
/___/
Texas Instruments ASIC Circuit Design Methodology Group
Dallas, Texas, 214-480-4455, b-patton@ti.com
Paul Pluzhnikov

2004-11-02, 5:54 pm

"Billy N. Patton" <b-patton@ti.com> writes:

> I define NULL as
> #define NULL '\0'


That is a really bad idea (TM).

> Seems to work in both c and c++ for solaris 8 and redhat enterprise


When something "seems to work" and you do not understand why,
you are programming "by conincidence":
http://www.pragmaticprogrammer.com/...oincidence.html

One problem with your definition is that on some machines, this
code will abort:

void *p = NULL;
if (p) abort();

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Bjorn Reese

2004-11-03, 5:53 pm

On Tue, 02 Nov 2004 05:55:11 -0600, Billy N. Patton wrote:

> I define NULL as
> #define NULL '\0'


Your definition makes NULL a character. When you pass this character
through a variadic list, it is automatically converted into int, so
in this case your definition is no different than defining NULL as
0. So, Paul's original comment about differently sized data types on
64-bit CPUs (LP64 architectures to be correct) still hold.

Terminating the variadic list with "(char *)0" is the best option.

--
mail1dotstofanetdotdk

Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com