Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: I think this is a disadvantag

Reply
Thread Tools

Re: I think this is a disadvantag

 
 
Xavier Roche
Guest
Posts: n/a
 
      06-15-2013
Le 15/06/2013 14:24, paskali a écrit :
> int sum(int num) {
> return sum;


You are returning a function (pointer) of a function taking an integer,
and returning an integer, casted to an integer. Except the implicit
cast, and the possible loss of data (the function pointer might have a
larger size than the integer), this is perfectly valid C (ugly, but valid).

It could be written as something like:
return (int) (int (*)(int)) sum;

If you compile this program with gcc, you should get some warning
telling you that something fishy is going on:
1.c:3:5: warning: return makes integer from pointer without a cast
[enabled by default]

 
Reply With Quote
 
 
 
 
Xavier Roche
Guest
Posts: n/a
 
      06-15-2013
Le 15/06/2013 15:34, paskali a écrit :
> sum += num[c];


You are trying to increment a function pointer, which can not be
modified (constant). The two "sum" symbols share the same namespace, you
have to use another name.

 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      06-15-2013
On 06/15/2013 08:46 AM, Xavier Roche wrote:
> Le 15/06/2013 14:24, paskali a �crit :
>> int sum(int num) {
>> return sum;

>
> You are returning a function (pointer) of a function taking an integer,
> and returning an integer, casted to an integer. Except the implicit
> cast, and the possible loss of data (the function pointer might have a
> larger size than the integer), this is perfectly valid C (ugly, but valid).
>
> It could be written as something like:
> return (int) (int (*)(int)) sum;
>
> If you compile this program with gcc, you should get some warning
> telling you that something fishy is going on:
> 1.c:3:5: warning: return makes integer from pointer without a cast
> [enabled by default]


I've used languages (I can't remember which ones, right now) where a
function definition like the following:

int sum(int num)
{
while(num-->0)
sum += num;
}

Was equivalent to the following C code:

int sum(int num)
{
int sum = 0; // Declaration hides function declaration
while(num-->0)
sum += num;
return sum;
}

In other words, there was an implicit definition of a local variable
with the same name as the function, with a type matching the return type
of the function, and an implicit return of the value of that value upon
exiting the function. Perhaps he's used such languages, and doesn't
understand how to do the equivalent thing in C?
--
James Kuyper
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      06-15-2013
On 15-Jun-13 12:51, James Kuyper wrote:
> I've used languages (I can't remember which ones, right now) where a
> function definition like the following:
>
> int sum(int num)
> {
> while(num-->0)
> sum += num;
> }
>
> Was equivalent to the following C code:
>
> int sum(int num)
> {
> int sum = 0; // Declaration hides function declaration
> while(num-->0)
> sum += num;
> return sum;
> }
>
> In other words, there was an implicit definition of a local variable
> with the same name as the function, with a type matching the return
> type of the function, and an implicit return of the value of that
> value upon exiting the function.


IIRC, that's how Visual Basic functions work. I don't recall seeing
that construct in any other language.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      06-15-2013
On 06/15/2013 04:29 PM, Robert Wessel wrote:
> On Sat, 15 Jun 2013 15:08:14 -0500, Stephen Sprunk
> <(E-Mail Removed)> wrote:
>
>> On 15-Jun-13 12:51, James Kuyper wrote:
>>> I've used languages (I can't remember which ones, right now) where a
>>> function definition like the following:
>>>
>>> int sum(int num)
>>> {
>>> while(num-->0)
>>> sum += num;
>>> }
>>>
>>> Was equivalent to the following C code:
>>>
>>> int sum(int num)
>>> {
>>> int sum = 0; // Declaration hides function declaration
>>> while(num-->0)
>>> sum += num;
>>> return sum;
>>> }
>>>
>>> In other words, there was an implicit definition of a local variable
>>> with the same name as the function, with a type matching the return
>>> type of the function, and an implicit return of the value of that
>>> value upon exiting the function.

>>
>> IIRC, that's how Visual Basic functions work. I don't recall seeing
>> that construct in any other language.


I've written BASIC code, but that was 35 years ago. I think that was
before it evolved into VB.

> Fortran, Pascal...


I thought it was Fortran I was remembering, but it's been a quarter
century since the last time I did any serious Fortran programming, so I
wasn't sure.
--
James Kuyper
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-15-2013
Xavier Roche <(E-Mail Removed)> writes:
> Le 15/06/2013 14:24, paskali a écrit :
>> int sum(int num) {
>> return sum;

>
> You are returning a function (pointer) of a function taking an integer,
> and returning an integer, casted to an integer. Except the implicit
> cast, and the possible loss of data (the function pointer might have a
> larger size than the integer), this is perfectly valid C (ugly, but valid).


No, it's not valid C. The name "sum" does refer to the function, but
there is no implicit conversion from pointer types to integer types.
(Note "implicit conversion", not "implicit cast"; a cast is by
definition an explicit conversion, specified by a cast operator,
a type name in parentheses.)

> It could be written as something like:
> return (int) (int (*)(int)) sum;


There's no need for the inner cast; sum is already of type int(*)(int)
(after the implicit conversion from function to pointer-to-function_).

The outer cast has undefined behavior (by omission, because the standard
doesn't define the behavior of a conversion of a function pointer to an
integer).

> If you compile this program with gcc, you should get some warning
> telling you that something fishy is going on:
> 1.c:3:5: warning: return makes integer from pointer without a cast
> [enabled by default]


And IMHO this should be a fatal error, not just a warning. It's a
constraint violation. (A mere warning satisfies the standard's
requirement for a diagnostic, but I personally dislike gcc's default
laxity.)

In any case, I can't think of any good reason to write code like that,
unless it's to discuss why one shouldn't write code like that.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Xavier Roche
Guest
Posts: n/a
 
      06-16-2013
Le 16/06/2013 01:19, Keith Thompson a écrit :
>> If you compile this program with gcc, you should get some warning
>> telling you that something fishy is going on:
>> 1.c:3:5: warning: return makes integer from pointer without a cast
>> [enabled by default]

>
> And IMHO this should be a fatal error, not just a warning.


Old code probably is using that (ie. casting a function pointer to a
32-bit int). uintptr_t is a rather "recent" (cough cough) addition.

 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-16-2013
James Kuyper <(E-Mail Removed)> writes:

> On 06/15/2013 04:29 PM, Robert Wessel wrote:
>>> [snip]

>>
>> Fortran, Pascal...

>
> I thought it was Fortran I was remembering, but it's been a
> quarter century since the last time I did any serious Fortran
> programming, so I wasn't sure.


If it was really at least 25 years ago, the programming was in
FORTRAN, not Fortran. FORTRAN didn't become Fortran until the
1991 version of its standard (ISO/IEC standard 1539:1991).
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-16-2013
Keith Thompson <(E-Mail Removed)> writes:

> Xavier Roche <(E-Mail Removed)> writes:
>> Le 15/06/2013 14:24, paskali a @C3{A9}crit :
>>> int sum(int num) {
>>> return sum;

>>
>> You are returning a function (pointer) of a function taking an integer,
>> and returning an integer, casted to an integer. Except the implicit
>> cast, and the possible loss of data (the function pointer might have a
>> larger size than the integer), this is perfectly valid C (ugly, but valid).

>
> No, it's not valid C. The name "sum" does refer to the function, but
> there is no implicit conversion from pointer types to integer types.
> (Note "implicit conversion", not "implicit cast"; a cast is by
> definition an explicit conversion, specified by a cast operator,
> a type name in parentheses.)
>
>> It could be written as something like:
>> return (int) (int (*)(int)) sum;

>
> There's no need for the inner cast; sum is already of type int(*)(int)
> (after the implicit conversion from function to pointer-to-function_).
>
> The outer cast has undefined behavior (by omission, because the standard
> doesn't define the behavior of a conversion of a function pointer to an
> integer).


Not that I want to disagree, but how do you reconcile that statement
with 6.3.2.3 p6?

Any pointer type may be converted to an integer type. Except
as previously specified, the result is implementation-defined.
 
Reply With Quote
 
Geoff
Guest
Posts: n/a
 
      06-16-2013
On Sun, 16 Jun 2013 06:56:50 -0700, Tim Rentsch
<(E-Mail Removed)> wrote:

>James Kuyper <(E-Mail Removed)> writes:
>
>> On 06/15/2013 04:29 PM, Robert Wessel wrote:
>>>> [snip]
>>>
>>> Fortran, Pascal...

>>
>> I thought it was Fortran I was remembering, but it's been a
>> quarter century since the last time I did any serious Fortran
>> programming, so I wasn't sure.

>
>If it was really at least 25 years ago, the programming was in
>FORTRAN, not Fortran. FORTRAN didn't become Fortran until the
>1991 version of its standard (ISO/IEC standard 1539:1991).


FORTRAN didn't need a standard to change it's capitalization any more
than LASER or RADAR need a standard to become laser or radar. Acronyms
such as these succumb to common usage, not some standardization
document that was probably following the historical usage and not
leading it.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Who can explain this bug? mathog C Programming 57 06-11-2013 10:09 PM
How do I encode and decode this data to write to a file? cl@isbd.net Python 11 05-01-2013 11:36 PM
Why does this incorrect CRTP static_cast compile? kfrank29.c@gmail.com C++ 2 04-25-2013 01:38 PM
This looks like a Perl bug George Mpouras Perl Misc 18 04-21-2013 11:56 PM
Really throwing this out there - does anyone have a copy of my oldDancer web browser? steven.miale@gmail.com Python 1 04-10-2013 03:32 PM



Advertisments