Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] GTK2 Tree: build, patch, and one smoking shot

Terminating argument in a vararg list is not standardized (or necessary,
if the program can infer the length of arguments from other parameters,
such as printf which knows based on the formatting strings you
included). I've usually encountered NULL, but some arguments (such as
GTK's GValue vararg arrays) seem to use -1.

-Seth

Quoting Silenio Quarti <Silenio_Quarti@xxxxxxx>:

> Yes, this is what we did on Motif (including the tralling NULL
> (-1?)). 
> 
> Silenio
> 
> 
> 
> 
> 
> "Steve Northover" <Steve_Northover@xxxxxxx>
> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
> 09/19/02 09:52 AM
> Please respond to platform-swt-dev
> 
>  
>         To:     platform-swt-dev@xxxxxxxxxxx
>         cc:     platform-swt-dev@xxxxxxxxxxx
>         Subject:        Re: [platform-swt-dev] GTK2 Tree: build,
> patch, and one smoking shot
> 
> 
> What we did on Motif was type in the varargs combinations that we
> actually
> used.
> I think we also forced the programmer to supply the -1.  SSQ?
> 
> 
> 
>   
>                       "Boris Shingarov"   
>                       <Boris_Shingarov@xxxxxx         To: 
> platform-swt-dev@xxxxxxxxxxx  
>                       M>                              cc:      
>                       Sent by:                        Subject: Re: 
> [platform-swt-dev] GTK2 Tree: build, patch, and one smoking shot 
>                       platform-swt-dev-admin@    
>                       eclipse.org   
>   
>   
>                       09/18/02 04:59 PM   
>                       Please respond to   
>                       platform-swt-dev   
>   
>   
> 
> 
> 
> 
> I agree here.  Silenio and I did discuss the problem with varargs a
> while
> ago, and decided to just follow the ostrich algorithm (stick your
> head in
> the sand and pretend there are no varargs) for now.  It does not
> cause 
> real
> problems for SWT implementation; having a one-arg version is enough
> for
> anything I needed so far.  I agree this is world-class-ugly though.
> 
> 
>  
>    snickell@xxxxxxxxxxxx 
>    Sent by:                         To: 
>    platform-swt-dev-admin@e platform-swt-dev@xxxxxxxxxxx 
>    clipse.org                       cc: 
>                                     Subject:        Re: 
>                             [platform-swt-dev] GTK2 Tree: build,
> patch, 
>    09/18/2002 04:22 PM      and one smoking shot 
>    Please respond to 
>    platform-swt-dev 
>  
> 
> 
> 
> 
> 
> Boris wrote:
> "Agreed in general (a lot of C code there that's WEIRD), but not in
> the
> particular case of varargs.  How is
> 
> set_value(int, boolean)
> set_value(int, int)
> set_value(int, String)
> 
> with the appropriate C code (full signatures), weirder than
> 
> set_value_boolean(int, boolean)
> set_value_int(int, int)
> set_value_string(int, String)?"
> 
> That's not really addressing the vararg issue, only the issue of
> wrapping GValues (which isn't too bad, I'll admit).
> 
> The vararg problem is that the GTK function accepts a list of values
> of
> undefined length (terminating in -1), or the same wrappered in the
> va_list type (which is what a received digs out of a vararg call,
> but
> isn't totally trivial to build). How do you want me to wrap this?
> Given
> the constraints of the SWT APIs, only one value at a time can be
> changed
> anyway, so IMO this is a bunch of functionally useless code since
> only
> only column's value will be changed at once anyway in SWT (and hence
> wrappering this by only accepting one value makes everything
> simpler).
> 
> The alternative is accepting an array to the function, unpacking the
> array, and generating a va_list. This is going to be a hell of a lot
> more complicated, error prone, and difficult to debug than accepting
> a
> single argumument.
> 
> -Seth
> 
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
> 
> 
> 
> 
> 
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
> 
> 
> 
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
> 


Back to the top