Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #24688 > unrolled thread
| Started by | Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> |
|---|---|
| First post | 2012-08-21 20:36 +0000 |
| Last post | 2012-08-24 02:37 -0700 |
| Articles | 3 on this page of 43 — 17 participants |
Back to article view | Back to comp.lang.c
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 3 of 3 — ← Prev page 1 2 [3]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-23 16:31 -0700 |
| Message-ID | <ln4nntgp7e.fsf@nuthaus.mib.org> |
| In reply to | #24803 |
Melzzzzz <mel@zzzzz.com> writes:
> 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 compiler *could* issue a warning (because the conversion is
potentially unsafe), but most don't. A cast, particularly a pointer
cast, is effectively a way of telling the compiler "Shut up, I know what
I'm doing".
Are you saying you'd *want* a warning for the cast?
>> 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.
Converting from one pointer type to another using a cast is not an
error, though the result is implementation-defined, and using the
converted pointer can lead to undefined behavior.
*Assigning* a pointer value of one type to an object of another
incompatible pointer type is a constraint violation (apart from
special cases involving void*). Likewise for initialization and
argument passing.
> 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 word "incompatible" has a specific meaning in C, and it's not
related to the sizes of the types. For example, `int*` and `long*` are
incompatible, even if `int` and `long` happen to have exactly the same
size and representation.
> 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.
I'm still not sure what you're saying. A compiler *must* issue a
diagnostic for an assignment between incompatible pointer types.
In my opinion, that diagnostic *should* be a fatal error.
Are you saying that a mere warning is preferable? Why?
--
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]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2012-08-24 18:31 +0200 |
| Message-ID | <k18a9b$2i0$2@news.albasani.net> |
| In reply to | #24808 |
On Thu, 23 Aug 2012 16:31:49 -0700 Keith Thompson <kst-u@mib.org> wrote: > Melzzzzz <mel@zzzzz.com> writes: > > 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 compiler *could* issue a warning (because the conversion is > potentially unsafe), but most don't. A cast, particularly a pointer > cast, is effectively a way of telling the compiler "Shut up, I know > what I'm doing". > > Are you saying you'd *want* a warning for the cast? Well, warning would be welcome , yes ;) > > > > 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. > > I'm still not sure what you're saying. A compiler *must* issue a > diagnostic for an assignment between incompatible pointer types. > In my opinion, that diagnostic *should* be a fatal error. > > Are you saying that a mere warning is preferable? Why? I think that forcing to cast from one type to another is just too verbose, but I'm not sure anymore since Im now changing my mind. All in all you two (James) convinced me that I am wrong...
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-08-24 02:37 -0700 |
| Message-ID | <6406b7b5-8ad9-45f3-927d-edf522e1e697@d13g2000yqm.googlegroups.com> |
| In reply to | #24792 |
On Aug 23, 9:33 pm, Melzzzzz <m...@zzzzz.com> wrote:
> On Thu, 23 Aug 2012 16:20:55 -0400
> James Kuyper <jameskuy...@verizon.net> wrote:
> > On 08/23/2012 04:09 PM, Melzzzzz wrote:
> > > On Thu, 23 Aug 2012 15:36:00 -0400
> > > James Kuyper <jameskuy...@verizon.net> wrote:
> > >> On 08/23/2012 03:21 PM, Melzzzzz wrote:
> > >>> On Thu, 23 Aug 2012 11:13:54 -0400
> > >>> James Kuyper <jameskuy...@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?
Melzzzzz, isn't the term "dangerously bad code" unclear in some way?
> > > 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.
since when was "reduce[ing] number of casts" a programming goal?
Reducing *unnecessary* casts, yes
> > 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?
my personnel (and company) programming standards require a warning
free compile. System test won't start testing code until it compiles
without warnings (for some Microsoft errors this actually means
suppressing some warnigns).
> 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] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.lang.c
csiph-web