| Author |
Message |
|
Hallvard B Furuset
#1 / 11
|
 va_arg(ap, const char *) = char*? Can va_arg(ap, const char *) fail if the argument is plain 'char *',
or va_arg(ap, char *) fail if the argument is 'const char *'?
--
Hallvard
|
| Sun, 04 Sep 2005 03:03:11 GMT |
|
 |
|
Derk Gwe
#2 / 11
|
va_arg(ap, const char *) = char*?
# Can va_arg(ap, const char *) fail if the argument is plain 'char *',
# or va_arg(ap, char *) fail if the argument is 'const char *'?
With var-args you should not assume the original types of the arguments
are in anyway saved. Or even the number of arguments or the types. All you
are given is a bit string of unknown length; it is up to you to partition that
into typed values with successive va_arg() calls. It's entirely your
responsibility not to assign a bit string an incompatiable type (such
as odd integer made (int*) on some cpus). If that happens, the results
are undefined and the compiler will probably not include enough information
for an automated detection and analysis of the failure.
--
Derk Gwen http://www.*-*-*.com/
Death is the worry of the living. The dead, like myself,
only worry about decay and {*filter*}cs.
|
| Sun, 04 Sep 2005 10:13:45 GMT |
|
|
|
Hallvard B Furuset
#3 / 11
|
va_arg(ap, const char *) = char*? Quote:
> # Can va_arg(ap, const char *) fail if the argument is plain 'char *', > # or va_arg(ap, char *) fail if the argument is 'const char *'? > With var-args you should not assume the original types of the
> arguments are in anyway saved. (...) It's entirely your responsibility
> not to assign a bit string an incompatiable type (such as odd integer
> made (int*) on some cpus).
I know. I just wondered if treaing char* as const char* could cause
trouble. Anyway, I found the answer myself in ANSI 3.1.2.5 (Types):
A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type. Similarly, pointers
to qualified or unqualified versions of compatible types shall have
the same representation and alignment requirements. (...)
Which means I can also pass NULL to a char*, BTW. That's nice.
--
Hallvard
|
| Sun, 04 Sep 2005 18:46:06 GMT |
|
|
|
Jeremy Yallo
#4 / 11
|
va_arg(ap, const char *) = char*? Quote:
> Which means I can also pass NULL to a char*, BTW.
You can't portably pass NULL to an unprototyped or variadic function
that expects a pointer to char. NULL may have integer type.
Jeremy.
|
| Sun, 04 Sep 2005 19:01:57 GMT |
|
|
|
Dan P
#5 / 11
|
va_arg(ap, const char *) = char*?
Quote: >I know. I just wondered if treaing char* as const char* could cause >trouble. Anyway, I found the answer myself in ANSI 3.1.2.5 (Types): > A pointer to void shall have the same representation and alignment
> requirements as a pointer to a character type. Similarly, pointers
> to qualified or unqualified versions of compatible types shall have
> the same representation and alignment requirements. (...)
>Which means I can also pass NULL to a char*, BTW. That's nice.
NULL to char *. Even the following code is broken:
printf("%p\n", NULL);
The correct version being
printf("%p\n", (void *)NULL);
Dan
--
Dan Pop
DESY Zeuthen, RZ group
|
| Sun, 04 Sep 2005 21:56:29 GMT |
|
|
|
#6 / 11
|
va_arg(ap, const char *) = char*?
|
| Wed, 18 Jun 1902 08:00:00 GMT |
|
|
|
Hallvard B Furuset
#7 / 11
|
va_arg(ap, const char *) = char*? [Followup-To: comp.std.c]
Quote:
> You can't portably pass NULL to an unprototyped or variadic function
> that expects a pointer to char. NULL may have integer type.
Oops, you are right. All the standard says is that it 'expands to an
implementation-defined null pointer constant'. Which means it could
even be (int*)0, which cannot be assigned to e.g. a char* without
casting it. (Though the library section makes a few more restrictions
since it uses NULL a few places without casting it.)
It seems to me that NULL as currently defined is completely useless:
Since we always must cast it, we could just as well cast 0.
A lot of code uses NULL without casting it.
I've had the impression that NULL must have the same size, alignment and
representation as (void*)0, and that's true on the systems I have seen.
Would it be possible to mandate this in a future version of the
standard?
--
Hallvard
|
| Sun, 04 Sep 2005 23:45:27 GMT |
|
|
|
Hallvard B Furuset
#8 / 11
|
va_arg(ap, const char *) = char*? Quote:
> [Followup-To: comp.std.c]
I shouldn't have done that so quickly. comp.lang.c readers, you can
stop telling me I was wrong now:-)
--
Hallvard
|
| Mon, 05 Sep 2005 16:58:07 GMT |
|
|
|
pete
#9 / 11
|
va_arg(ap, const char *) = char*? Quote:
> > [Followup-To: comp.std.c]
> I shouldn't have done that so quickly. comp.lang.c readers, you can
> stop telling me I was wrong now:-)
Your "future version of the standard" is the prefered topic,
on comp.std.c
--
pete
|
| Mon, 05 Sep 2005 19:55:54 GMT |
|
|
|
#10 / 11
|
va_arg(ap, const char *) = char*?
|
| Wed, 18 Jun 1902 08:00:00 GMT |
|
|
|
Zoran Cutur
#11 / 11
|
va_arg(ap, const char *) = char*?
Quote: > Can va_arg(ap, const char *) fail if the argument is plain 'char *',
> or va_arg(ap, char *) fail if the argument is 'const char *'?
Let's see.
7.15.1.1 The va_arg macro
2 ... If there is no actual next argument, or if type is not
compatible with the type of the actual next argument (as
promoted according to the default argument promotions), the
behavior is undefined, except for the following cases:
- one type is a signed integer type, the other type
is the corresponding unsigned integer type, and the value is
representable in both types;
- one type is pointer to void and the other
is a pointer to a character type.
so the question is are the two types const char * and char *
compatible? And I think they are not, because:
6.7.3 Type qualifiers
9 ... For two qualified types to be compatible, both shall have the
identically qualified version of a compatible type; ...
and
6.7.5.1 Pointer declarators
2 For two pointer types to be compatible, both shall be
identically qualified and both shall be pointers to compatible
types.
So that pointing to a char isn't compatible to pointing to a const
char.
But I may be interpreting the standard in a wrong way.
--
profound enlightenment experience you will have when you finally get
it; that experience will make you a better programmer for the rest of
your days." -- Eric S. Raymond
|
| Tue, 06 Sep 2005 02:01:08 GMT |
|
| |
