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

Groups > comp.std.c > #1382 > unrolled thread

Conversion from void* to pointer-to-function?

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

Contents

  Conversion from void* to pointer-to-function? Keith Thompson <kst-u@mib.org> - 2012-06-25 13:26 -0700
    Re: Conversion from void* to pointer-to-function? James Kuyper <jameskuyper@verizon.net> - 2012-06-25 17:23 -0400
      Re: Conversion from void* to pointer-to-function? Keith Thompson <kst-u@mib.org> - 2012-06-25 14:57 -0700
        Re: Conversion from void* to pointer-to-function? Maxim Fomin <maxim@maxim-fomin.ru> - 2012-06-27 10:03 -0700
          Re: Conversion from void* to pointer-to-function? Keith Thompson <kst-u@mib.org> - 2012-06-27 11:33 -0700
            Re: Conversion from void* to pointer-to-function? David R Tribble <david@tribble.com> - 2012-07-24 20:05 -0700
    Re: Conversion from void* to pointer-to-function? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-21 00:32 -0800
      Re: Conversion from void* to pointer-to-function? Tijl Coosemans <tijl@coosemans.org> - 2012-12-21 10:00 +0100
      Re: Conversion from void* to pointer-to-function? Keith Thompson <kst-u@mib.org> - 2012-12-21 02:01 -0800
        Re: Conversion from void* to pointer-to-function? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-21 08:12 -0800
          Re: Conversion from void* to pointer-to-function? Keith Thompson <kst-u@mib.org> - 2012-12-21 17:58 -0800
            Re: Conversion from void* to pointer-to-function? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-22 08:22 -0800

#1382 — Conversion from void* to pointer-to-function?

Consider the following toy program:

int main(void) {   
    void *void_ptr = 0;
    void (*func_ptr)(void) = (void(*)(void))void_ptr;
    return 0;
}

(Note that void_ptr is *not* a null pointer constant, it's merely a
pointer object that happens to contain a null pointer.)

Is the conversion of void_ptr to void(*)(void) (a pointer-to-function
type) permitted?

N1570 6.5.4 lists three constraints for the cast operator. This code
doesn't violate any of them.

N1570 6.3.2.3 describes the semantics of conversions involving pointers.
It mentions conversions from void* to and from pointer-to-object types,
conversions from one pointer-to-object type to another, and conversions
from one pointer-to-function type to another.  Conversions from void* to
a pointer-to-function type simply aren't mentioned.

My conclusion is that the conversion is permitted (it doesn't violate
any constraint or syntax rule), but its behavior is undefined by
omission.

Note that the authors of gcc seem to have a different interpretation;
on the above code, gcc-4.7 with "-std=c99 -pedantic" produces the
following warning:

    warning: ISO C forbids conversion of object pointer to function pointer type [-pedantic]

Frankly I think it would make more sense if the conversion *were*
a constraint violation, or else if its behavior were explicitly
stated to be undefined (or the result to be implementation-defined
or unspecified).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [next] | [standalone]

#1383

On 06/25/2012 04:26 PM, Keith Thompson wrote:
> Consider the following toy program:
> 
> int main(void) {   
>     void *void_ptr = 0;
>     void (*func_ptr)(void) = (void(*)(void))void_ptr;
>     return 0;
> }
> 
> (Note that void_ptr is *not* a null pointer constant, it's merely a
> pointer object that happens to contain a null pointer.)
> 
> Is the conversion of void_ptr to void(*)(void) (a pointer-to-function
> type) permitted?
> 
> N1570 6.5.4 lists three constraints for the cast operator. This code
> doesn't violate any of them.
> 
> N1570 6.3.2.3 describes the semantics of conversions involving pointers.
> It mentions conversions from void* to and from pointer-to-object types,
> conversions from one pointer-to-object type to another, and conversions
> from one pointer-to-function type to another.  Conversions from void* to
> a pointer-to-function type simply aren't mentioned.

Conversion of null pointers to other pointer types is mentioned
(6.3.6.3p4). It applies only to null pointers being converted to pointer
types, but there are no other type-based restrictions on the
applicability of that section.

> My conclusion is that the conversion is permitted (it doesn't violate
> any constraint or syntax rule), but its behavior is undefined by
> omission.

The behavior is defined by 6.3.6.3p4: it produces a null pointer of type
void(*)(void).

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

#1384

James Kuyper <jameskuyper@verizon.net> writes:
> On 06/25/2012 04:26 PM, Keith Thompson wrote:
>> Consider the following toy program:
>> 
>> int main(void) {   
>>     void *void_ptr = 0;
>>     void (*func_ptr)(void) = (void(*)(void))void_ptr;
>>     return 0;
>> }
>> 
>> (Note that void_ptr is *not* a null pointer constant, it's merely a
>> pointer object that happens to contain a null pointer.)
>> 
>> Is the conversion of void_ptr to void(*)(void) (a pointer-to-function
>> type) permitted?
>> 
>> N1570 6.5.4 lists three constraints for the cast operator. This code
>> doesn't violate any of them.
>> 
>> N1570 6.3.2.3 describes the semantics of conversions involving pointers.
>> It mentions conversions from void* to and from pointer-to-object types,
>> conversions from one pointer-to-object type to another, and conversions
>> from one pointer-to-function type to another.  Conversions from void* to
>> a pointer-to-function type simply aren't mentioned.
>
> Conversion of null pointers to other pointer types is mentioned
> (6.3.6.3p4). It applies only to null pointers being converted to pointer
> types, but there are no other type-based restrictions on the
> applicability of that section.
>
>> My conclusion is that the conversion is permitted (it doesn't violate
>> any constraint or syntax rule), but its behavior is undefined by
>> omission.
>
> The behavior is defined by 6.3.6.3p4: it produces a null pointer of type
> void(*)(void).

It's 6.3.2.3p4, not 6.3.6.3p4.

You're right, of course -- which makes me realize I didn't ask what I
intended to ask.  I meant to ask about conversion from void* to a
pointer-to-function type in general, not about conversion of null
pointers.

A revised test case:

#include <stdlib.h>
#include <assert.h>
int main(void) {   
    void *void_ptr = malloc(1024);
    assert(void_ptr != NULL);
    void (*func_ptr)(void) = (void(*)(void))void_ptr;
    return 0;
}

Assume that the assert doesn't fire.

I believe that the conversion in the initializer for void_ptr is
legal (i.e., doesn't violate any syntax rule or constraint) but has
undefined behavior by omission.  (The authors of gcc, based on the
warning given with "gcc -std=c99 -pedantic", apparently disagree.)

Is my interpretation correct?

I know that the standard explicitly allows for undefined behavior when
the behavior is quietly not specified, but IMHO the standard would be
improved if 6.3.2.3 covered this case and explicitly stated that the
behavior is undefined.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#1387

вторник, 26 июня 2012 г., 1:57:34 UTC+4 пользователь Keith Thompson написал:
> James Kuyper <jameskuyper@verizon.net> writes:
> > On 06/25/2012 04:26 PM, Keith Thompson wrote:
> >> Consider the following toy program:
> >> 
> >> int main(void) {   
> >>     void *void_ptr = 0;
> >>     void (*func_ptr)(void) = (void(*)(void))void_ptr;
> >>     return 0;
> >> }
> >> 
> >> (Note that void_ptr is *not* a null pointer constant, it's merely a
> >> pointer object that happens to contain a null pointer.)
> >> 
> >> Is the conversion of void_ptr to void(*)(void) (a pointer-to-function
> >> type) permitted?
> >> 
> >> N1570 6.5.4 lists three constraints for the cast operator. This code
> >> doesn't violate any of them.
> >> 
> >> N1570 6.3.2.3 describes the semantics of conversions involving pointers.
> >> It mentions conversions from void* to and from pointer-to-object types,
> >> conversions from one pointer-to-object type to another, and conversions
> >> from one pointer-to-function type to another.  Conversions from void* to
> >> a pointer-to-function type simply aren't mentioned.
> >
> > Conversion of null pointers to other pointer types is mentioned
> > (6.3.6.3p4). It applies only to null pointers being converted to pointer
> > types, but there are no other type-based restrictions on the
> > applicability of that section.
> >
> >> My conclusion is that the conversion is permitted (it doesn't violate
> >> any constraint or syntax rule), but its behavior is undefined by
> >> omission.
> >
> > The behavior is defined by 6.3.6.3p4: it produces a null pointer of type
> > void(*)(void).
> 
> It's 6.3.2.3p4, not 6.3.6.3p4.
> 
> You're right, of course -- which makes me realize I didn't ask what I
> intended to ask.  I meant to ask about conversion from void* to a
> pointer-to-function type in general, not about conversion of null
> pointers.
> 
> A revised test case:
> 
> #include <stdlib.h>
> #include <assert.h>
> int main(void) {   
>     void *void_ptr = malloc(1024);
>     assert(void_ptr != NULL);
>     void (*func_ptr)(void) = (void(*)(void))void_ptr;
>     return 0;
> }
> 
> Assume that the assert doesn't fire.
> 
> I believe that the conversion in the initializer for void_ptr is
> legal (i.e., doesn't violate any syntax rule or constraint) but has
> undefined behavior by omission.  (The authors of gcc, based on the
> warning given with "gcc -std=c99 -pedantic", apparently disagree.)
> 
> Is my interpretation correct?
> 
> I know that the standard explicitly allows for undefined behavior when
> the behavior is quietly not specified, but IMHO the standard would be
> improved if 6.3.2.3 covered this case and explicitly stated that the
> behavior is undefined.
> 
> -- 
> Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
>     Will write code for food.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

I think there is another interpretation of this issue.

6.2.5 p.20: "A pointer type may be derived from a function type or an object type, called the referenced type".
"referenced type" is highlighted and supposed to be important.

6.3.2.1 p.8: "If a converted pointer is used to call a function whose type is not compatible with the referenced type, the behavior is undefined."

So, this statement should be applied to both object and function pointers and not only to function pointers. 6.2.5 states that there are two groups of pointers: pointers-to-object and pointers-to function. It doesn't state that there is a third case of void* pointer, so void* should be pointer-to-object because its type is incomplete (object types may be incomplete) and it may be freely converted to any pointer to object.

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

#1388

Maxim Fomin <maxim@maxim-fomin.ru> writes:
[...]
>> A revised test case:
>> 
>> #include <stdlib.h>
>> #include <assert.h>
>> int main(void) {   
>>     void *void_ptr = malloc(1024);
>>     assert(void_ptr != NULL);
>>     void (*func_ptr)(void) = (void(*)(void))void_ptr;
>>     return 0;
>> }
>> 
>> Assume that the assert doesn't fire.
>> 
>> I believe that the conversion in the initializer for void_ptr is
>> legal (i.e., doesn't violate any syntax rule or constraint) but has
>> undefined behavior by omission.  (The authors of gcc, based on the
>> warning given with "gcc -std=c99 -pedantic", apparently disagree.)
>> 
>> Is my interpretation correct?
>> 
>> I know that the standard explicitly allows for undefined behavior when
>> the behavior is quietly not specified, but IMHO the standard would be
>> improved if 6.3.2.3 covered this case and explicitly stated that the
>> behavior is undefined.
>
> I think there is another interpretation of this issue.
>
> 6.2.5 p.20: "A pointer type may be derived from a function type or an
> object type, called the referenced type".  "referenced type" is
> highlighted and supposed to be important.

"referenced type" is in italics, which simply means that this is the
definition of the term (see 3p1).

> 6.3.2.1 p.8: "If a converted pointer is used to call a function whose
> type is not compatible with the referenced type, the behavior is
> undefined."

That's not relevant to this case. It refers to calling a function with a
function pointer of the wrong type. The prefix of a function call is an
expression of pointer-to-function type; see 6.5.2.2p1. If the prefix is
a pointer to an object type, that's a constraint violation.

> So, this statement should be applied to both object and function
> pointers and not only to function pointers. 6.2.5 states that there
> are two groups of pointers: pointers-to-object and pointers-to
> function. It doesn't state that there is a third case of void*
> pointer, so void* should be pointer-to-object because its type is
> incomplete (object types may be incomplete) and it may be freely
> converted to any pointer to object.

In C99, types are partitioned into object types, function types, and
incomplete types (void is an incompletetype).

C11 changes this; now types are partitioned into function typed and
object types. An object type may be incomplete or complete.  (6.2.5p1).

Certainly void* may be converted to any pointer to object. My question
is about converting void* to a pointer to function.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#1402

On Wednesday, June 27, 2012 1:33:23 PM UTC-5, Keith Thompson wrote:
> Certainly void* may be converted to any pointer to object. My question
> is about converting void* to a pointer to function.

Well, it's certainly going to invoke undefined (or at least
implementation-defined) behavior on architectures having
sizeof(void (*)()) != sizeof(void *), i.e., function
pointers of different (usually wider) sizes.

-drt

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

#1781

Keith Thompson <kst-u@mib.org> writes:

> Consider the following toy program:
>
> int main(void) {   
>     void *void_ptr = 0;
>     void (*func_ptr)(void) = (void(*)(void))void_ptr;
>     return 0;
> }
>
> (Note that void_ptr is *not* a null pointer constant, it's merely a
> pointer object that happens to contain a null pointer.)
>
> Is the conversion of void_ptr to void(*)(void) (a pointer-to-function
> type) permitted?
>
> N1570 6.5.4 lists three constraints for the cast operator. This code
> doesn't violate any of them.
>
> N1570 6.3.2.3 describes the semantics of conversions involving pointers.
> It mentions conversions from void* to and from pointer-to-object types,
> conversions from one pointer-to-object type to another, and conversions
> from one pointer-to-function type to another.  Conversions from void* to
> a pointer-to-function type simply aren't mentioned.
>
> My conclusion is that the conversion is permitted (it doesn't violate
> any constraint or syntax rule), but its behavior is undefined by
> omission.

I agree with this conclusion.

> Note that the authors of gcc seem to have a different interpretation;
> on the above code, gcc-4.7 with "-std=c99 -pedantic" produces the
> following warning:
>
>     warning: ISO C forbids conversion of object pointer to function pointer type [-pedantic]

I interpret gcc's message differently, especially since it is a
warning.  Since there is at least potential confusion about
whether the ISO standard allows such conversions, they feel
obliged to give a diagnostic (but without preventing compilation)
to be on the safe side for being a conforming implementation.
When in doubt, issue a diagnostic - no harm for being wrong
on that side of the fence.

> Frankly I think it would make more sense if the conversion *were*
> a constraint violation, or else if its behavior were explicitly
> stated to be undefined (or the result to be implementation-defined
> or unspecified).

The problem is, for this particular case none of those categories
are really quite right.  One implementation might think it's okay
and sensible and perfectly acceptable, whereas another might
choose to treat it as an unrecoverable translation failure.  It
isn't just executing such a conversion, but even writing an
expression (ie, a cast) that specifies such a conversion, crosses
over into undefined behavior.  And, apparently the Standard wants
to give all of that latitude, in both directions (including not
having to issue any diagnostics), for implementations to use as
they see fit.  I don't know offhand of any other construct that
falls into exactly this category.

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

#1782

On 21-12-2012 09:32, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
>> Consider the following toy program:
>>
>> int main(void) {   
>>     void *void_ptr = 0;
>>     void (*func_ptr)(void) = (void(*)(void))void_ptr;
>>     return 0;
>> }
>>
>> (Note that void_ptr is *not* a null pointer constant, it's merely a
>> pointer object that happens to contain a null pointer.)
>>
>> Is the conversion of void_ptr to void(*)(void) (a pointer-to-function
>> type) permitted?
>>
>> N1570 6.5.4 lists three constraints for the cast operator. This code
>> doesn't violate any of them.
>>
>> N1570 6.3.2.3 describes the semantics of conversions involving pointers.
>> It mentions conversions from void* to and from pointer-to-object types,
>> conversions from one pointer-to-object type to another, and conversions
>> from one pointer-to-function type to another.  Conversions from void* to
>> a pointer-to-function type simply aren't mentioned.
>>
>> My conclusion is that the conversion is permitted (it doesn't violate
>> any constraint or syntax rule), but its behavior is undefined by
>> omission.
> 
> I agree with this conclusion.
> 
>> Note that the authors of gcc seem to have a different interpretation;
>> on the above code, gcc-4.7 with "-std=c99 -pedantic" produces the
>> following warning:
>>
>>     warning: ISO C forbids conversion of object pointer to function pointer type [-pedantic]
> 
> I interpret gcc's message differently, especially since it is a
> warning.  Since there is at least potential confusion about
> whether the ISO standard allows such conversions, they feel
> obliged to give a diagnostic (but without preventing compilation)
> to be on the safe side for being a conforming implementation.
> When in doubt, issue a diagnostic - no harm for being wrong
> on that side of the fence.
> 
>> Frankly I think it would make more sense if the conversion *were*
>> a constraint violation, or else if its behavior were explicitly
>> stated to be undefined (or the result to be implementation-defined
>> or unspecified).
> 
> The problem is, for this particular case none of those categories
> are really quite right.  One implementation might think it's okay
> and sensible and perfectly acceptable, whereas another might
> choose to treat it as an unrecoverable translation failure.  It
> isn't just executing such a conversion, but even writing an
> expression (ie, a cast) that specifies such a conversion, crosses
> over into undefined behavior.  And, apparently the Standard wants
> to give all of that latitude, in both directions (including not
> having to issue any diagnostics), for implementations to use as
> they see fit.  I don't know offhand of any other construct that
> falls into exactly this category.

As an example POSIX requires that function pointers can be cast to
void* and back. It's marked as an extension of the C standard.

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

#1783

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Keith Thompson <kst-u@mib.org> writes:
>
>> Consider the following toy program:
>>
>> int main(void) {   
>>     void *void_ptr = 0;
>>     void (*func_ptr)(void) = (void(*)(void))void_ptr;
>>     return 0;
>> }
[...]
>> My conclusion is that the conversion is permitted (it doesn't violate
>> any constraint or syntax rule), but its behavior is undefined by
>> omission.
>
> I agree with this conclusion.
>
>> Note that the authors of gcc seem to have a different interpretation;
>> on the above code, gcc-4.7 with "-std=c99 -pedantic" produces the
>> following warning:
>>
>>     warning: ISO C forbids conversion of object pointer to function pointer type [-pedantic]
>
> I interpret gcc's message differently, especially since it is a
> warning.  Since there is at least potential confusion about
> whether the ISO standard allows such conversions, they feel
> obliged to give a diagnostic (but without preventing compilation)
> to be on the safe side for being a conforming implementation.
> When in doubt, issue a diagnostic - no harm for being wrong
> on that side of the fence.

gcc issues mere warnings for a lot of things that are constraint
violations.  The -pedantic option is intended to enable all the
diagnostics that the standard requires.  The -pedantic-errors
option makes those diagnostics fatal.  With -pedantic-errors,
the above warning becomes a fatal error.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#1789

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Consider the following toy program:
>>>
>>> int main(void) {   
>>>     void *void_ptr = 0;
>>>     void (*func_ptr)(void) = (void(*)(void))void_ptr;
>>>     return 0;
>>> }
> [...]
>>> My conclusion is that the conversion is permitted (it doesn't violate
>>> any constraint or syntax rule), but its behavior is undefined by
>>> omission.
>>
>> I agree with this conclusion.
>>
>>> Note that the authors of gcc seem to have a different interpretation;
>>> on the above code, gcc-4.7 with "-std=c99 -pedantic" produces the
>>> following warning:
>>>
>>>     warning: ISO C forbids conversion of object pointer to function pointer type [-pedantic]
>>
>> I interpret gcc's message differently, especially since it is a
>> warning.  Since there is at least potential confusion about
>> whether the ISO standard allows such conversions, they feel
>> obliged to give a diagnostic (but without preventing compilation)
>> to be on the safe side for being a conforming implementation.
>> When in doubt, issue a diagnostic - no harm for being wrong
>> on that side of the fence.
>
> gcc issues mere warnings for a lot of things that are constraint
> violations.  [snip elaboration]

That's good to know, but I'm not sure it changes my reaction.
Do you have some other examples readily at hand?

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

#1795

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> gcc issues mere warnings for a lot of things that are constraint
>> violations.  [snip elaboration]
>
> That's good to know, but I'm not sure it changes my reaction.
> Do you have some other examples readily at hand?

$ cat c.c
int main(void) {
    int x;
    int y = &x;
    main + 1;
    sizeof (void);
}
$ gcc -c -std=c11 -pedantic -c c.c
c.c: In function ‘main’:
c.c:3:13: warning: initialization makes integer from pointer without a cast [enabled by default]
c.c:4:10: warning: pointer to a function used in arithmetic [-pedantic]
c.c:5:13: warning: invalid application of ‘sizeof’ to a void type [-pedantic]
$ gcc -c -std=c11 -pedantic-errors -c c.c
c.c: In function ‘main’:
c.c:3:13: error: initialization makes integer from pointer without a cast
c.c:4:10: error: pointer to a function used in arithmetic [-pedantic]
c.c:5:13: error: invalid application of ‘sizeof’ to a void type
[-pedantic]
$ 

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#1798

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
> [...]
>>> gcc issues mere warnings for a lot of things that are constraint
>>> violations.  [snip elaboration]
>>
>> That's good to know, but I'm not sure it changes my reaction.
>> Do you have some other examples readily at hand?
>
> $ cat c.c
> int main(void) {
>     int x;
>     int y = &x;
>     main + 1;
>     sizeof (void);
> }
> $ gcc -c -std=c11 -pedantic -c c.c
> c.c: In function 'main':
> c.c:3:13: warning: initialization makes integer from pointer without a cast [enabled by default]
> c.c:4:10: warning: pointer to a function used in arithmetic [-pedantic]
> c.c:5:13: warning: invalid application of 'sizeof' to a void type [-pedantic]
> $ gcc -c -std=c11 -pedantic-errors -c c.c
> c.c: In function 'main':
> c.c:3:13: error: initialization makes integer from pointer without a cast
> c.c:4:10: error: pointer to a function used in arithmetic [-pedantic]
> c.c:5:13: error: invalid application of 'sizeof' to a void type
> [-pedantic]
> $ 

Great example!  Thank you.

[toc] | [prev] | [standalone]

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

csiph-web