Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #59126 > unrolled thread

Variadic functions and const

Back to article view | Back to comp.lang.c

Contents

  Variadic functions and const samuelallenalexander@gmail.com - 2015-03-28 05:54 -0700
    Re: Variadic functions and const Lőrinczy Zsigmond <nospam@for.me> - 2015-03-28 14:38 +0100
    Re: Variadic functions and const Richard Damon <Richard@Damon-Family.org> - 2015-03-28 10:02 -0400
    Re: Variadic functions and const Kaz Kylheku <kaz@kylheku.com> - 2015-03-28 14:11 +0000
    Re: Variadic functions and const Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-28 15:13 +0000
    Re: Variadic functions and const fir <profesor.fir@gmail.com> - 2015-03-28 08:34 -0700
      Re: Variadic functions and const fir <profesor.fir@gmail.com> - 2015-03-28 08:38 -0700
      Re: Variadic functions and const Lőrinczy Zsigmond <nospam@for.me> - 2015-03-28 17:01 +0100
        Re: Variadic functions and const Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-28 12:49 -0700

#59126 — Variadic functions and const

Dear comp.lang.c,

Really surprised I can't find this discussed anywhere.  In a C variadic function's prototype, is there any way to specify the const status of the variables?  It doesn't seem like there is.  We can imagine, for example, a function which takes int N along with N char *'s, and NULs the first char of each of those char *'s:

void nullify_strings( int N, ... )
{
  char *s;
  va_list vargs;

  for ( va_start(vargs, N); N > 0; N-- )
    *( (s = va_arg(vargs,char*)) ) = '\0';

  va_end(vargs);
}

But there's nothing in the prototype warning people (or compilers) that const char *'s shouldn't be passed to this function.  Is the above nullify_strings function valid?  If a naive space alien only had access to printf's prototype, but not to its man pages, would that alien be able to deduce that printf("%s","Hello World") is safe?

Regards,
Sam

[toc] | [next] | [standalone]

#59129

> In a C variadic function's prototype,
 > is there any way to specify the const status of the variables?

Certainly not.
You cannot even define the _number_ of variadic parameters,
let alone their type or const-ness.

[toc] | [prev] | [next] | [standalone]

#59130

On 3/28/15 8:54 AM, samuelallenalexander@gmail.com wrote:
> Dear comp.lang.c,
>
> Really surprised I can't find this discussed anywhere.  In a C
> variadic function's prototype, is there any way to specify the const
> status of the variables?  It doesn't seem like there is.  We can
> imagine, for example, a function which takes int N along with N char
> *'s, and NULs the first char of each of those char *'s:
>
> void nullify_strings( int N, ... )
 > {
 >   char *s;
>   va_list vargs;
>
>   for ( va_start(vargs, N); N > 0; N-- )
 >     *( (s = va_arg(vargs,char*)) ) = '\0';
>
>   va_end(vargs);
 > }
>
> But there's nothing in the prototype warning people (or compilers)
> that const char *'s shouldn't be passed to this function.  Is the
> above nullify_strings function valid?  If a naive space alien only
> had access to printf's prototype, but not to its man pages, would
> that alien be able to deduce that printf("%s","Hello World") is
> safe?
>
> Regards, Sam
>

This is one of the cases where C will gladly give you enough rope to
hang yourself.

Variadic functions have one simple rule, the caller MUST provide the
parameters in proper order and type that the function will take, or
undefined behavior occurs. Normally, there is something in the 
parameters provided that tells the called function what to expect 
(otherwise why not just use a fixed prototype), but the caller must 
provide this information correctly and within the restrictions of what 
the called function expect.

The prototype can provide no help on this, as it is always just ...

The documentation for the function should specify this information (or 
the function isn't very useful).

One extension that I think I have seen (it might have been for another C 
like language) for this case, where all the varidic parameters were the 
same was to define the function slightly differently, something like:

void nullify_strings( int N, char* ...)

note, the added type, and no comma between the type and the ...

[toc] | [prev] | [next] | [standalone]

#59132

On 2015-03-28, samuelallenalexander@gmail.com <samuelallenalexander@gmail.com> wrote:
> Dear comp.lang.c,
>
> Really surprised I can't find this discussed anywhere.  In a C variadic
> function's prototype, is there any way to specify the const status of the
> variables?

"const" is a type qualifier.  The trailing arguments of a variadic function
do not have a declared type. So there is nothing there that a const could
qualify.

> void nullify_strings( int N, ... )
> {
>   char *s;
>   va_list vargs;
>
>   for ( va_start(vargs, N); N > 0; N-- )
>     *( (s = va_arg(vargs,char*)) ) = '\0';
>
>   va_end(vargs);
> }

You are free to code this as

  const char *s;

  /* ... */

  s = va_arg(vargs, const char *)

(and of course drop the mutating assignment). Then document to the users
that this treats strings as const char *.

> But there's nothing in the prototype warning people (or compilers) that const
> char *'s shouldn't be passed to this function.

Indeed: namely, there is no type information for the trailing arguments.

You can call it as follows, and no diagnostic is required:

  struct foo { int x; } s;

  nullify_strings(42, 4.0E+23, s, &s);

[toc] | [prev] | [next] | [standalone]

#59139

samuelallenalexander@gmail.com writes:

> Really surprised I can't find this discussed anywhere.  In a C
> variadic function's prototype, is there any way to specify the const
> status of the variables?  It doesn't seem like there is.

Actually you are asking about the const status of the things pointed to
by the arguments.

But this is to pick an point to contest -- you can't get any type
information about the arguments at all!  In your example, passing a
int * would be as bad as passing a char * and passing an in or float
would probably be worse.

<snip>
> But there's nothing in the prototype warning people (or compilers)
> that const char *'s shouldn't be passed to this function.  Is the
> above nullify_strings function valid?  If a naive space alien only had
> access to printf's prototype, but not to its man pages, would that
> alien be able to deduce that printf("%s","Hello World") is safe?

No.  But then the same is true of thousands of other cases:

  strcpy(x, 0);
  malloc(0);
  strcat("abc", "def");
  memcpy(x, x + 1, 1);

C is very weakly typed and a function prototype says very little about
what calls are safe.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#59141

(not an answer but side note about 

foo(data*); 

passing in c

c has extreme hole here that might be 
extremally confusing esp if working with
second party libraries,
you just dont know
1) if this data is passed to read
2) if is passed to write
3) if is consumed (i mean may be internally dealocated by some free(), seems probably very rare case in reality but in strict sense you never know (if im not wrong))
4) if this data is produced (may be mallocked)
5) if needs to be sustained (on caller side) 
(becouse only pointer was passed snd setted to oryginal data that are steel needed to be referenced) or if they may and should be destroyed after this call
6, 7.. ) maybe even other cases im not sure

i was deadly condused with such things working
with some libs (even more in other languages than in c, as you also have not clearly stated
what the real case is also there), this is like some damn small coding dellirium here ;/
(thats why it needs to be repaired)

[toc] | [prev] | [next] | [standalone]

#59142

W dniu sobota, 28 marca 2015 16:34:56 UTC+1 użytkownik fir napisał:
> (not an answer but side note about 
> 
> foo(data*); 
> 
> passing in c
> 
> c has extreme hole here that might be 
> extremally confusing esp if working with
> second party libraries,
> you just dont know
> 1) if this data is passed to read
> 2) if is passed to write
> 3) if is consumed (i mean may be internally dealocated by some free(), seems probably very rare case in reality but in strict sense you never know (if im not wrong))
> 4) if this data is produced (may be mallocked)
> 5) if needs to be sustained (on caller side) 
> (becouse only pointer was passed snd setted to oryginal data that are steel needed to be referenced) or if they may and should be destroyed after this call
> 6, 7.. ) maybe even other cases im not sure
> 
> i was deadly condused with such things working
> with some libs (even more in other languages than in c, as you also have not clearly stated
> what the real case is also there), this is like some damn small coding dellirium here ;/
> (thats why it needs to be repaired)

ps may sociological question becouse of curiosity

- does other people also noticed this 'delirium' in such cases or i am the only one that was haunted by this? 
- id so how was the cure for it, or they just ignore this or what?

[toc] | [prev] | [next] | [standalone]

#59145

You mean there should be a language where syntax can
substitute documentation?

[toc] | [prev] | [next] | [standalone]

#59159

On Saturday, March 28, 2015 at 4:02:07 PM UTC, Lőrinczy Zsigmond wrote:
>
> You mean there should be a language where syntax can
> substitute documentation?
>
That's often the goal.

For example Javascript is hard to "hack" because, to give real
example, I was modifying some code which set up a slider. 

            var options = {

                $AutoPlay: true,                                   //[Optional] Whether to auto play, to enable slideshow, this option must be set to true, default value is false
                $DragOrientation: 3                               //[Optional] Orientation to drag slide, 0 no drag, 1 horizental, 2 vertical, 3 either, default value is 1 (Note that the $DragOrientation should be the same as $PlayOrientation when $DisplayPieces is greater than 1, or parking position is not 0)
            };

            var jssor_slider1 = new $JssorSlider$("slider1_container", options);
 
So using the comments you can see how to toggle the slider from
autoplay to play on click, and on orientation. But it stretches
the image to fill the slider. You can of course turn stretching off.

To do that you must add $FillMode: 1

But you've no way of guessing by looking at the code. If Javascript
didn't have duck typing, and syntax forced explicit initialisation,
you see
  $FillMode : 0

It's still not quite clear what that does or means. But a natural thing
to do is to set it to 1 and see the effect. As it is, you need to
go to the documentation. Arguably a good thing, because hacking is
considered bad by many, but that's another discussion.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web