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

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

Function factories

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

Contents

  Function factories Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2012-08-21 20:36 +0000
    Re: Function factories Nobody <nobody@nowhere.com> - 2012-08-21 21:55 +0100
      Re: Function factories Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2012-08-22 16:36 +0000
        Re: Function factories James Kuyper <jameskuyper@verizon.net> - 2012-08-22 13:01 -0400
          Re: Function factories Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2012-08-22 18:33 +0000
          Re: Function factories James Kuyper <jameskuyper@verizon.net> - 2012-08-22 22:26 -0400
    Re: Function factories David Brown <david@westcontrol.removethisbit.com> - 2012-08-22 08:34 +0200
      Re: Function factories Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-22 01:52 -0700
        Re: Function factories David Brown <david@westcontrol.removethisbit.com> - 2012-08-22 11:34 +0200
        Re: Function factories Gareth Owen <gwowen@gmail.com> - 2012-08-24 17:30 +0100
      Re: Function factories Gareth Owen <gwowen@gmail.com> - 2012-08-24 17:29 +0100
    Re: Function factories jacob navia <jacob@spamsink.net> - 2012-08-22 12:32 +0200
      Re: Function factories tom st denis <tom@iahu.ca> - 2012-08-22 07:40 -0700
        Re: Function factories James Kuyper <jameskuyper@verizon.net> - 2012-08-22 11:05 -0400
          Re: Function factories jacob navia <jacob@spamsink.net> - 2012-08-23 11:08 +0200
          Re: Function factories Chicken McNuggets <chicken@mcnuggets.com> - 2012-08-23 13:27 +0100
            Re: Function factories James Kuyper <jameskuyper@verizon.net> - 2012-08-23 11:13 -0400
              Re: Function factories "Heinrich Wolf" <invalid@invalid.invalid> - 2012-08-23 18:18 +0200
                Re: Function factories James Kuyper <jameskuyper@verizon.net> - 2012-08-23 12:40 -0400
              Re: Function factories Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2012-08-23 09:29 -0700
                Re: Function factories jacob navia <jacob@spamsink.net> - 2012-08-23 18:44 +0200
                Re: Function factories James Kuyper <jameskuyper@verizon.net> - 2012-08-23 12:46 -0400
              Re: Function factories Chicken McNuggets <chicken@mcnuggets.com> - 2012-08-23 18:02 +0100
                Re: Function factories jacob navia <jacob@spamsink.net> - 2012-08-23 19:24 +0200
                  Re: Function factories eq mail <eq.mail.id@gmail.com> - 2012-08-23 18:07 -0700
                    Re: Function factories Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-23 21:30 -0400
                      Re: Function factories eq mail <eq.mail.id@gmail.com> - 2012-08-23 21:46 -0700
                Re: Function factories James Kuyper <jameskuyper@verizon.net> - 2012-08-23 13:35 -0400
                  Re: Function factories jacob navia <jacob@spamsink.net> - 2012-08-23 20:13 +0200
                Re: Function factories eq mail <eq.mail.id@gmail.com> - 2012-08-23 17:57 -0700
                Re: Function factories Andrew Cooper <amc96@cam.ac.uk> - 2012-08-25 02:35 +0100
              Re: Function factories Melzzzzz <mel@zzzzz.invalid> - 2012-08-23 21:21 +0200
                Re: Function factories James Kuyper <jameskuyper@verizon.net> - 2012-08-23 15:36 -0400
                  Re: Function factories Melzzzzz <mel@zzzzz.invalid> - 2012-08-23 22:09 +0200
                    Re: Function factories James Kuyper <jameskuyper@verizon.net> - 2012-08-23 16:20 -0400
                      Re: Function factories Melzzzzz <mel@zzzzz.com> - 2012-08-23 22:33 +0200
                        Re: Function factories James Kuyper <jameskuyper@verizon.net> - 2012-08-23 17:07 -0400
                        Re: Function factories Keith Thompson <kst-u@mib.org> - 2012-08-23 14:51 -0700
                          Re: Function factories Melzzzzz <mel@zzzzz.com> - 2012-08-24 00:09 +0200
                            Re: Function factories James Kuyper <jameskuyper@verizon.net> - 2012-08-23 19:01 -0400
                            Re: Function factories Keith Thompson <kst-u@mib.org> - 2012-08-23 16:31 -0700
                              Re: Function factories Melzzzzz <mel@zzzzz.com> - 2012-08-24 18:31 +0200
                        Re: Function factories Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-24 02:37 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#24758

Le 23/08/12 18:29, Anand Hariharan a écrit :
> On Aug 23, 10:13 am, James Kuyper <jameskuy...@verizon.net> wrote:
>> On 08/23/2012 08:27 AM, Chicken McNuggets wrote:
>>
>>> On 22/08/2012 16:05, James Kuyper wrote:
>>
>>>> However, I think that compile() looks horribly type-unsafe.
>>
>>> Type safety in C? That's a novel concept :).
>>
>> Is it? Try compiling the following code:
>>
>> int main(void)
>> {
>>          double d;
>>          int *pi = &d;
>>          return 0;
>> }
>
> One additional line (that doesn't involve any casts) is sufficient -
>
> int main(void)
> {
>      double d;
>      void *pv = &d;
>      int *pi = pv;
>      return 0;
> }
>
> $ gcc -W -Wall -ansi -pedantic foo.c
> foo.c: In function ‘main’:
> foo.c:6:10: warning: unused variable ‘pi’
>
>

C allows you to interpret ANY part of memory as something else if you 
(as you have shown) are careful to avoid the built-in barriers of the 
language.

Interpreting doubles as integers is very useful if you want to test
some bits or manipulate some bits of the binary representation without
going through expensive floating point operations. The whole Sun math 
library is built using this kind of code, and you can do that in C since 
it is a language that doesn't IMPOSE anything to the programmer, like 
C#, C++ or Cwhatever.

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

#24759

On 08/23/2012 12:29 PM, Anand Hariharan wrote:
> On Aug 23, 10:13 am, James Kuyper <jameskuy...@verizon.net> wrote:
>> On 08/23/2012 08:27 AM, Chicken McNuggets wrote:
>>
>>> On 22/08/2012 16:05, James Kuyper wrote:
>>
>>>> However, I think that compile() looks horribly type-unsafe.
>>
>>> Type safety in C? That's a novel concept :).
>>
>> Is it? Try compiling the following code:
>>
>> int main(void)
>> {
>>         double d;
>>         int *pi = &d;
>>         return 0;
>> }
> 
> One additional line (that doesn't involve any casts) is sufficient -
> 
> int main(void)
> {
>     double d;
>     void *pv = &d;
>     int *pi = pv;
>     return 0;
> }

Sure, C's support of type safety is weak, and easily circumvented. But
it's not non-existent, as implied by Chicken's first comment above. I've
used several languages with substantially less type safety; mostly ones
where type mismatches are not detected until something blows up at run
time. I greatly prefer catching them at compile time (a concept which
doesn't even apply to some of those languages).

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

#24762

On 23/08/2012 16:13, James Kuyper wrote:
> On 08/23/2012 08:27 AM, Chicken McNuggets wrote:
>> On 22/08/2012 16:05, James Kuyper wrote:
>>
>>>
>>> However, I think that compile() looks horribly type-unsafe.
>>>
>>
>> Type safety in C? That's a novel concept :).
>
> Is it? Try compiling the following code:
>
> int main(void)
> {
> 	double d;
> 	int *pi = &d;
> 	return 0;
> }
>

Yes. It compiles with a warning as expected. Not a great example of type 
safety.

This code on the other hand compiles with no warnings:

#include <stdlib.h>

int main(void)
{
	int *ptr = (int*) malloc(sizeof(long));
	*ptr = 10;
	short blah = *ptr;
	free(ptr);
	exit(EXIT_SUCCESS);
}

so please explain how C is a type safe language?

The fact that malloc() returns a void pointer that can be cast to any 
type destroys any type safety C may have.

Try Haskell for a real type safe language.

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

#24763

Le 23/08/12 19:02, Chicken McNuggets a écrit :
> On 23/08/2012 16:13, James Kuyper wrote:
>> On 08/23/2012 08:27 AM, Chicken McNuggets wrote:
>>> On 22/08/2012 16:05, James Kuyper wrote:
>>>
>>>>
>>>> However, I think that compile() looks horribly type-unsafe.
>>>>
>>>
>>> Type safety in C? That's a novel concept :).
>>
>> Is it? Try compiling the following code:
>>
>> int main(void)
>> {
>>     double d;
>>     int *pi = &d;
>>     return 0;
>> }
>>
>
> Yes. It compiles with a warning as expected. Not a great example of type
> safety.
>
> This code on the other hand compiles with no warnings:
>
> #include <stdlib.h>
>
> int main(void)
> {
>      int *ptr = (int*) malloc(sizeof(long));
>      *ptr = 10;
>      short blah = *ptr;
>      free(ptr);
>      exit(EXIT_SUCCESS);
> }
>
> so please explain how C is a type safe language?
>

Because you can assign a 64 bit integer into a short. If there is an 
overflow the behavior is undefined but it can't be any overflow in your 
example since 10 will fit into a short.

What is the problem?

> The fact that malloc() returns a void pointer that can be cast to any
> type destroys any type safety C may have.
>
> Try Haskell for a real type safe language.

OK
Lets suppose I have a double precision number and that I want to reset
the sign bit without doing any expensive floating point operations.

How do I do that in Haskell?

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

#24812

On 23/08/2012, 20:24, jacob navia wrote:
> Le 23/08/12 19:02, Chicken McNuggets a crit :
> > This code on the other hand compiles with no warnings:
>
> > #include <stdlib.h>
>
> > int main(void)
> > {
> >      int *ptr = (int*) malloc(sizeof(long));
> >      *ptr = 10;
> >      short blah = *ptr;
> >      free(ptr);
> >      exit(EXIT_SUCCESS);
> > }
>
> > so please explain how C is a type safe language?
>
> Because you can assign a 64 bit integer into a short.

Is that really an explanation for how C is a type safe language?

> If there is an overflow the behavior is undefined
> but it can't be any overflow in your example since
> 10 will fit into a short.

Integer conversions, such as the one above, do not yield undefined
behaviour.

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

#24813

On 8/23/2012 9:07 PM, eq mail wrote:
> On 23/08/2012, 20:24, jacob navia wrote:
>> Le 23/08/12 19:02, Chicken McNuggets a crit :
>>> This code on the other hand compiles with no warnings:
>>
>>> #include <stdlib.h>
>>
>>> int main(void)
>>> {
>>>       int *ptr = (int*) malloc(sizeof(long));
>>>       *ptr = 10;
>>>       short blah = *ptr;
>>>       free(ptr);
>>>       exit(EXIT_SUCCESS);
>>> }
>>
>>> so please explain how C is a type safe language?
>>
>> Because you can assign a 64 bit integer into a short.
>
> Is that really an explanation for how C is a type safe language?
>
>> If there is an overflow the behavior is undefined
>> but it can't be any overflow in your example since
>> 10 will fit into a short.
>
> Integer conversions, such as the one above, do not yield undefined
> behaviour.

     The program is (technically) at risk of undefined behavior
on any machine where sizeof(int) > sizeof(long).  No such machine
has ever been rumored, but would be within the realm of possibility
for a C implementation: int might be 40 bits wide (including 15
padding bits) while long is 32 with no padding.

     Also, there's the possibility that malloc() returns NULL.

     But turning to the conversion: Yes, it's well-defined -- But
that's only because the value 10 is within both the range of int
and the range of short.  Change the 10 to 123456789101112 and you
get quite a different picture.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#24815

On 24/08/2012, 4:30, Eric Sosman wrote:
> On 8/23/2012 9:07 PM, eq mail wrote:
> > On 23/08/2012, 20:24, jacob navia wrote:
> >> Le 23/08/12 19:02, Chicken McNuggets a crit :
> >>> This code on the other hand compiles with no warnings:
>
> >>> #include <stdlib.h>
>
> >>> int main(void)
> >>> {
> >>>       int *ptr = (int*) malloc(sizeof(long));
> >>>       *ptr = 10;
> >>>       short blah = *ptr;
> >>>       free(ptr);
> >>>       exit(EXIT_SUCCESS);
> >>> }
>
> >>> so please explain how C is a type safe language?
>
> >> Because you can assign a 64 bit integer into a short.
>
> > Is that really an explanation for how C is a type safe language?
>
> >> If there is an overflow the behavior is undefined
> >> but it can't be any overflow in your example since
> >> 10 will fit into a short.
>
> > Integer conversions, such as the one above, do not yield undefined
> > behaviour.
>
>      The program is (technically) at risk of undefined behavior
> on any machine where sizeof(int) > sizeof(long).  No such machine
> has ever been rumored, but would be within the realm of possibility
> for a C implementation: int might be 40 bits wide (including 15
> padding bits) while long is 32 with no padding.
>
>      Also, there's the possibility that malloc() returns NULL.

This is a strange reply. I chose not to dissect the example (although
I mentioned bad coding practices in general else-thread).

>      But turning to the conversion: Yes, it's well-defined -- But
> that's only because the value 10 is within both the range of int
> and the range of short.  Change the 10 to 123456789101112 and you
> get quite a different picture.

Yes and no. It won't be UB no matter what, so the statement still
stands.

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

#24764

On 08/23/2012 01:02 PM, Chicken McNuggets wrote:
> On 23/08/2012 16:13, James Kuyper wrote:
>> On 08/23/2012 08:27 AM, Chicken McNuggets wrote:
>>> On 22/08/2012 16:05, James Kuyper wrote:
>>>
>>>>
>>>> However, I think that compile() looks horribly type-unsafe.
>>>>
>>>
>>> Type safety in C? That's a novel concept :).
>>
>> Is it? Try compiling the following code:
>>
>> int main(void)
>> {
>> 	double d;
>> 	int *pi = &d;
>> 	return 0;
>> }
>>
> 
> Yes. It compiles with a warning as expected. Not a great example of type 
> safety.

It's a lot better than it would be if no warning were mandated. An
implementation is free to reject such code - whether or not it actually
does so is a matter of QoI, outside the scope of the standard.

> This code on the other hand compiles with no warnings:
> 
> #include <stdlib.h>
> 
> int main(void)
> {
> 	int *ptr = (int*) malloc(sizeof(long));
> 	*ptr = 10;
> 	short blah = *ptr;
> 	free(ptr);
> 	exit(EXIT_SUCCESS);
> }
> 
> so please explain how C is a type safe language?

Type safety is not an absolute yes or no issue. Some languages have more
type safety than others. C has static type checking - in many different
contexts, a diagnostic is mandatory if different types are not
compatible. Implicit conversions are often safe conversions, the most
dangerous type conversions are required to be explicit (except those
pointer conversions which can be done using void* as an intermediate
type). There's plenty of room for improvement in C's type safety, but
it's still a lot better than having no type checking, or deferring type
checking until run-time (both of which I've seen in other languages).

> The fact that malloc() returns a void pointer that can be cast to any 
> type destroys any type safety C may have.

No, it doesn't. It just adds another type-unsafe mechanism to a language
that has only a moderate amount of type safety without it.

lcc-win32's compile() looks to me like it compromises type safety much
more than malloc() does, which is what prompted my original comment. A
pointer to a function that might point have the wrong function type
seems much more serious to me than a pointer to an object that might
have the wrong object type; there's a larger variety of ways you can
have a mis-match, and a correspondingly larger number of different
failure modes available. It's not good, either way.

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

#24774

Le 23/08/12 19:35, James Kuyper a écrit :
> lcc-win32's compile() looks to me like it compromises type safety much
> more than malloc() does, which is what prompted my original comment. A
> pointer to a function that might point have the wrong function type
> seems much more serious to me than a pointer to an object that might
> have the wrong object type; there's a larger variety of ways you can
> have a mis-match, and a correspondingly larger number of different
> failure modes available. It's not good, either way.

But how can "compile()" know what type of function you are going to define?

There is absolutely NO WAY to change this fact. But of course if you
have one solution please let me know...

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

#24811

On 23/08/2012, 20:02, Chicken McNuggets wrote:
> On 23/08/2012 16:13, James Kuyper wrote:
> > On 08/23/2012 08:27 AM, Chicken McNuggets wrote:
> >> On 22/08/2012 16:05, James Kuyper wrote:
> > Is it? Try compiling the following code:
> >
> > int main(void)
> > {
> >    double d;
> >    int *pi = &d;
> >    return 0;
> > }
>
> Yes. It compiles with a warning as expected. Not a great example of type
> safety.

That's up to your implementation. The fact that you do get a
diagnostic tells that a level of type-safety is there, but you should
probably look for settings that would make such diagnostics also fatal
errors.

> This code on the other hand compiles with no warnings:
>
> #include <stdlib.h>
>
> int main(void)
> {
>         int *ptr = (int*) malloc(sizeof(long));
>         *ptr = 10;
>         short blah = *ptr;
>         free(ptr);
>         exit(EXIT_SUCCESS);
>
> }
>
> so please explain how C is a type safe language?

I don't think this specific example succeeds at showing the
deficiencies of C and it's type system nearly as much as it highlights
several bad coding practices and a pitfall of one standard library
function.

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

#24879

On 23/08/2012 18:02, Chicken McNuggets wrote:
> On 23/08/2012 16:13, James Kuyper wrote:
>> On 08/23/2012 08:27 AM, Chicken McNuggets wrote:
>>> On 22/08/2012 16:05, James Kuyper wrote:
>>>
>>>>
>>>> However, I think that compile() looks horribly type-unsafe.
>>>>
>>>
>>> Type safety in C? That's a novel concept :).
>>
>> Is it? Try compiling the following code:
>>
>> int main(void)
>> {
>>     double d;
>>     int *pi = &d;
>>     return 0;
>> }
>>
> 
> Yes. It compiles with a warning as expected. Not a great example of type
> safety.
> 
> This code on the other hand compiles with no warnings:
> 
> #include <stdlib.h>
> 
> int main(void)
> {
>     int *ptr = (int*) malloc(sizeof(long));
>     *ptr = 10;
>     short blah = *ptr;
>     free(ptr);
>     exit(EXIT_SUCCESS);
> }
> 
> so please explain how C is a type safe language?

C is not a strongly typed language.

Data is raw.
The numbers you find in RAM are just integers.

C will help you with types in 90% of cases, but the remaining 10% is
left up to the developer.  This is the price of having complete and
utter control over anything you need if you wish (with the option of
degrading to assembly if you absolutely need to).

~Andrew

> 
> The fact that malloc() returns a void pointer that can be cast to any
> type destroys any type safety C may have.
> 
> Try Haskell for a real type safe language.

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

#24779

On Thu, 23 Aug 2012 11:13:54 -0400
James Kuyper <jameskuyper@verizon.net> wrote:

> int main(void)
> {
> 	double d;
> 	int *pi = &d;
> 	return 0;
> }
gcc by default compiles just fine, but issues warning ;)
g++ gives error and that I don;t like ...


-- 
drwx------ 2 bmaxa bmaxa 4096 Aug 23 21:19 .

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

#24781

On 08/23/2012 03:21 PM, Melzzzzz wrote:
> On Thu, 23 Aug 2012 11:13:54 -0400
> James Kuyper <jameskuyper@verizon.net> wrote:
> 
>> int main(void)
>> {
>> 	double d;
>> 	int *pi = &d;
>> 	return 0;
>> }
> gcc by default compiles just fine, but issues warning ;)
> g++ gives error and that I don;t like ...

Personally, I like it when a compiler lets me know I've written
dangerously bad code. Why do you feel differently?

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

#24786

On Thu, 23 Aug 2012 15:36:00 -0400
James Kuyper <jameskuyper@verizon.net> wrote:

> On 08/23/2012 03:21 PM, Melzzzzz wrote:
> > On Thu, 23 Aug 2012 11:13:54 -0400
> > James Kuyper <jameskuyper@verizon.net> wrote:
> > 
> >> int main(void)
> >> {
> >> 	double d;
> >> 	int *pi = &d;
> >> 	return 0;
> >> }
> > gcc by default compiles just fine, but issues warning ;)
> > g++ gives error and that I don;t like ...
> 
> Personally, I like it when a compiler lets me know I've written
> dangerously bad code. Why do you feel differently?
> 

I wasn't clear. c++ issues error and that I don;t like,
while behavior of C compiler is just fine IMO ;)


-- 
drwx------ 2 bmaxa bmaxa 4096 Aug 23 22:07 .

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

#24790

On 08/23/2012 04:09 PM, Melzzzzz wrote:
> On Thu, 23 Aug 2012 15:36:00 -0400
> James Kuyper <jameskuyper@verizon.net> wrote:
> 
>> On 08/23/2012 03:21 PM, Melzzzzz wrote:
>>> On Thu, 23 Aug 2012 11:13:54 -0400
>>> James Kuyper <jameskuyper@verizon.net> wrote:
>>>
>>>> int main(void)
>>>> {
>>>> 	double d;
>>>> 	int *pi = &d;
>>>> 	return 0;
>>>> }
>>> gcc by default compiles just fine, but issues warning ;)
>>> g++ gives error and that I don;t like ...
>>
>> Personally, I like it when a compiler lets me know I've written
>> dangerously bad code. Why do you feel differently?
>>
> 
> I wasn't clear. c++ issues error and that I don;t like,
> while behavior of C compiler is just fine IMO ;)

No, you were quite clear, but perhaps my response wasn't. It seems to me
that treating such code as an error is entirely appropriate; a warning
seems inadequate. Why do you feel differently?

If you actually have a legitimate need to do the conversion, and know
something implementation-specific that makes is safer than it is in the
general case, make those facts explicit by using a cast (in C) or a
reinterpret_cast<> (in C++). Requiring something as clumsy and as easily
searched for as reinterpret_cast<> in order to perform such a dangerous
conversion also strikes me as a good idea.

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

#24792

On Thu, 23 Aug 2012 16:20:55 -0400
James Kuyper <jameskuyper@verizon.net> wrote:

> On 08/23/2012 04:09 PM, Melzzzzz wrote:
> > On Thu, 23 Aug 2012 15:36:00 -0400
> > James Kuyper <jameskuyper@verizon.net> wrote:
> > 
> >> On 08/23/2012 03:21 PM, Melzzzzz wrote:
> >>> On Thu, 23 Aug 2012 11:13:54 -0400
> >>> James Kuyper <jameskuyper@verizon.net> wrote:
> >>>
> >>>> int main(void)
> >>>> {
> >>>> 	double d;
> >>>> 	int *pi = &d;
> >>>> 	return 0;
> >>>> }
> >>> gcc by default compiles just fine, but issues warning ;)
> >>> g++ gives error and that I don;t like ...
> >>
> >> Personally, I like it when a compiler lets me know I've written
> >> dangerously bad code. Why do you feel differently?
> >>
> > 
> > I wasn't clear. c++ issues error and that I don;t like,
> > while behavior of C compiler is just fine IMO ;)
> 
> No, you were quite clear, but perhaps my response wasn't. It seems to
> me that treating such code as an error is entirely appropriate; a
> warning seems inadequate. Why do you feel differently?

It seems that reduces number of casts in code. Warning is enough
if it is accidental error.

> 
> If you actually have a legitimate need to do the conversion, and know
> something implementation-specific that makes is safer than it is in
> the general case, make those facts explicit by using a cast (in C) or
> a reinterpret_cast<> (in C++). Requiring something as clumsy and as
> easily searched for as reinterpret_cast<> in order to perform such a
> dangerous conversion also strikes me as a good idea.

Well compiler warnings are enough aren't they? Cast just masks warning
and makes compiler happy which is not good thing.
Well if you have to search trough code to find that one error is much
more difficult rather then just check compiler warning.
I don;t like to shut up compiler warnings with casts and that's
why C's approach is better.

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

#24798

On 08/23/2012 04:33 PM, Melzzzzz wrote:
> On Thu, 23 Aug 2012 16:20:55 -0400
> James Kuyper <jameskuyper@verizon.net> wrote:
> 
>> On 08/23/2012 04:09 PM, Melzzzzz wrote:
>>> On Thu, 23 Aug 2012 15:36:00 -0400
>>> James Kuyper <jameskuyper@verizon.net> wrote:
>>>
>>>> On 08/23/2012 03:21 PM, Melzzzzz wrote:
>>>>> On Thu, 23 Aug 2012 11:13:54 -0400
>>>>> James Kuyper <jameskuyper@verizon.net> wrote:
>>>>>
>>>>>> int main(void)
>>>>>> {
>>>>>> 	double d;
>>>>>> 	int *pi = &d;
>>>>>> 	return 0;
>>>>>> }
>>>>> gcc by default compiles just fine, but issues warning ;)
>>>>> g++ gives error and that I don;t like ...
>>>>
>>>> Personally, I like it when a compiler lets me know I've written
>>>> dangerously bad code. Why do you feel differently?
>>>>
>>>
>>> I wasn't clear. c++ issues error and that I don;t like,
>>> while behavior of C compiler is just fine IMO ;)
>>
>> No, you were quite clear, but perhaps my response wasn't. It seems to
>> me that treating such code as an error is entirely appropriate; a
>> warning seems inadequate. Why do you feel differently?
> 
> It seems that reduces number of casts in code. Warning is enough
> if it is accidental error.

As opposed to a deliberate error?
I have to disagree with you about whether reducing the number of casts
is a good idea. See below.

>> If you actually have a legitimate need to do the conversion, and know
>> something implementation-specific that makes is safer than it is in
>> the general case, make those facts explicit by using a cast (in C) or
>> a reinterpret_cast<> (in C++). Requiring something as clumsy and as
>> easily searched for as reinterpret_cast<> in order to perform such a
>> dangerous conversion also strikes me as a good idea.
> 
> Well compiler warnings are enough aren't they? Cast just masks warning
> and makes compiler happy which is not good thing.

No, in the unlikely event that you have legitimate reason to write such
code,  a cast explicitly requests that the conversion should occur (and
in some cases makes a conversion occur that could not occur implicitly).
It documents the developer's assertion that there is a legitimate reason
for performing what is ordinarily a rather dangerous operation. Code
that is correctly written to do what it does should not generate
warnings, even if it does use dangerous methods to get there. The danger
should be marked by the presence of the cast, not by generation of
warning messages. Producing warning messages from correct code
desensitizes developers to warning messages associated with incorrect
code. The cast should be easy to notice and search for, which is one
reason why reinterpret-cast<> is better than a C-style cast.

> Well if you have to search trough code to find that one error is much
> more difficult rather then just check compiler warning.

That doesn't explain why you think a compiler error is worse than a
compiler warning. If the error message is written properly, both will
give you the location of the problem, so there's no need to go searching.

> I don;t like to shut up compiler warnings with casts and that's
> why C's approach is better.

C doesn't make any different approach than C++ in this case; the
construct is equally an error in both languages, and neither language
specifies what an implementation should do about it, beyond issuing the
mandatory diagnostic. It's the compiler that's decided to handle these
two languages differently, not the language specifications.

Note that, given C's anti-aliasing rules, in the unlikely event that you
do have a legitimate reason to write code like that, it would be better
to use code like this:

	union { double d, int i} u;
	int *pi = &u.i;

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

#24800

Melzzzzz <mel@zzzzz.com> writes:
[...]
> Well compiler warnings are enough aren't they? Cast just masks warning
> and makes compiler happy which is not good thing.
> Well if you have to search trough code to find that one error is much
> more difficult rather then just check compiler warning.
> I don;t like to shut up compiler warnings with casts and that's
> why C's approach is better.

The code in question was:

    double d;
    int *pi = &d;

and the question is whether a compiler should reject it with an error
message or accept it with a mere warning.

Personally, I would never deliberately write that.  As far as the C
standard is concerned, it's a constraint violation, requiring a
diagnostic from any conforming compiler.  If a compiler issues a warning
and continues to compile the code, it might seem reasonable to assume
that it will generate a conversion from `double*` to `int*` -- but in
fact the language standard does not say or imply that that's what will
happen.  The behavior is undefined; a compiler could legally generate
code that sets `pi` to a null pointer, for example.

Whereas if I *want* to do that conversion, there's a perfectly valid way
to do it that likely won't result in a warning:

    double d;
    int *pi = (int*)&d;

A problem I have with gcc is that it doesn't clearly distinguish between
warnings about constraint violations, like the above, and warnings about
legal but questionable code, such as writing `if (x = 42)` rather than
`if (x == 42)`.  Again, this doesn't violate the C standard; I just
personally find it annoying.

That's just my opinion (that all syntax errors and constraint violations
should be treated as fatal errors, not as warnings -- or at least that
there should be an option that works that way).  What's yours?  Which
errors do you think should be fatal, and which should merely trigger a
warning?

-- 
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]

#24803

On Thu, 23 Aug 2012 14:51:59 -0700
Keith Thompson <kst-u@mib.org> wrote:

> Melzzzzz <mel@zzzzz.com> writes:
> [...]
> > Well compiler warnings are enough aren't they? Cast just masks
> > warning and makes compiler happy which is not good thing.
> > Well if you have to search trough code to find that one error is
> > much more difficult rather then just check compiler warning.
> > I don;t like to shut up compiler warnings with casts and that's
> > why C's approach is better.
> 
> The code in question was:
> 
>     double d;
>     int *pi = &d;
> 
> and the question is whether a compiler should reject it with an error
> message or accept it with a mere warning.
> 
> Personally, I would never deliberately write that.  As far as the C
> standard is concerned, it's a constraint violation, requiring a
> diagnostic from any conforming compiler.  If a compiler issues a
> warning and continues to compile the code, it might seem reasonable
> to assume that it will generate a conversion from `double*` to `int*`
> -- but in fact the language standard does not say or imply that
> that's what will happen.  The behavior is undefined; a compiler could
> legally generate code that sets `pi` to a null pointer, for example.

I didn't knew that this is undefined behavior.

> 
> Whereas if I *want* to do that conversion, there's a perfectly valid
> way to do it that likely won't result in a warning:
> 
>     double d;
>     int *pi = (int*)&d;
> 

Problem is that we wont get warning in this case IMO.

> A problem I have with gcc is that it doesn't clearly distinguish
> between warnings about constraint violations, like the above, and
> warnings about legal but questionable code, such as writing `if (x =
> 42)` rather than `if (x == 42)`.  Again, this doesn't violate the C
> standard; I just personally find it annoying.
> 
> That's just my opinion (that all syntax errors and constraint
> violations should be treated as fatal errors, not as warnings -- or
> at least that there should be an option that works that way).  What's
> yours?  Which errors do you think should be fatal, and which should
> merely trigger a warning?

I don't think that converting one pointer type to other is error.
It seems to me that in spirit of C it should be allowed as it is.
It should issue error if types are incompatible, say pointer to int
has less bytes than pointer to double.
Problem is that if code that uses such conversions will work at all.
Say copying data as int / reading as double.
It might work in one case and might not in other.
It would be very difficult to find out bug (wrong result etc) without
compiler warning IMO.

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

#24806

On 08/23/2012 06:09 PM, Melzzzzz wrote:
> On Thu, 23 Aug 2012 14:51:59 -0700
> Keith Thompson <kst-u@mib.org> wrote:
> 
>> Melzzzzz <mel@zzzzz.com> writes:
>> [...]
>>> Well compiler warnings are enough aren't they? Cast just masks
>>> warning and makes compiler happy which is not good thing.
>>> Well if you have to search trough code to find that one error is
>>> much more difficult rather then just check compiler warning.
>>> I don;t like to shut up compiler warnings with casts and that's
>>> why C's approach is better.
>>
>> The code in question was:
>>
>>     double d;
>>     int *pi = &d;
>>
>> and the question is whether a compiler should reject it with an error
>> message or accept it with a mere warning.
>>
>> Personally, I would never deliberately write that.  As far as the C
>> standard is concerned, it's a constraint violation, requiring a
>> diagnostic from any conforming compiler.  If a compiler issues a
>> warning and continues to compile the code, it might seem reasonable
>> to assume that it will generate a conversion from `double*` to `int*`
>> -- but in fact the language standard does not say or imply that
>> that's what will happen.  The behavior is undefined; a compiler could
>> legally generate code that sets `pi` to a null pointer, for example.
> 
> I didn't knew that this is undefined behavior.
> 
>>
>> Whereas if I *want* to do that conversion, there's a perfectly valid
>> way to do it that likely won't result in a warning:
>>
>>     double d;
>>     int *pi = (int*)&d;
>>
> 
> Problem is that we wont get warning in this case IMO.

You shouldn't. A cast is a way of saying "I'm doing something dangerous.
Trust me to know that I'm doing it right". If you don't know that the
conversion is safe, you shouldn't write the cast in the first place. If
you do know it's correct, a warning message would be inappropriate and
distracting. If you have a problem that you've traced into piece of code
containing a cast, you should always consider the possibility that the
cast is the problem.

>> A problem I have with gcc is that it doesn't clearly distinguish
>> between warnings about constraint violations, like the above, and
>> warnings about legal but questionable code, such as writing `if (x =
>> 42)` rather than `if (x == 42)`.  Again, this doesn't violate the C
>> standard; I just personally find it annoying.
>>
>> That's just my opinion (that all syntax errors and constraint
>> violations should be treated as fatal errors, not as warnings -- or
>> at least that there should be an option that works that way).  What's
>> yours?  Which errors do you think should be fatal, and which should
>> merely trigger a warning?
> 
> I don't think that converting one pointer type to other is error.

The C standard says otherwise. More precisely, depending upon the
context, it is sometimes a constraint violation, and sometimes has
undefined behavior for other reasons.

> It seems to me that in spirit of C it should be allowed as it is.
> It should issue error if types are incompatible, say pointer to int
> has less bytes than pointer to double.

The types are incompatible in this case, which is precisely what's wrong
with this code. I think you're using a different meaning for "compatible
types" than the C standard uses. Pointers to incompatible types are
themselves incompatible pointer types. Types of different sizes are
never compatible, regardless of which one is bigger, but types of the
same size can be incompatible too.

> Problem is that if code that uses such conversions will work at all.
> Say copying data as int / reading as double.
> It might work in one case and might not in other.
> It would be very difficult to find out bug (wrong result etc) without
> compiler warning IMO.

Keep in mind that, because the code contains a constraint violation, the
compiler is free to refuse to compile it, even if you're absolutely
certain that the code is safe. You'll have your compiler warning, but
you won't have a bug, because you won't have an executable.
If you're not certain, don't write such code. If you are certain, you
may need the cast to force your compiler to accept it.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web