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

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

Restricted unsigned integer range would have been better?

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

Contents

  Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-23 01:32 -0600
    Re: Restricted unsigned integer range would have been better? "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-07-23 01:45 -0700
      Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 00:19 -0600
        Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-24 11:25 +0100
          Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 16:22 -0600
            Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-25 01:53 +0100
              Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 21:43 -0600
        Re: Restricted unsigned integer range would have been better? "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-07-24 16:29 -0700
          Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 21:53 -0600
            Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-24 23:24 -0700
              Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 01:12 -0600
    Re: Restricted unsigned integer range would have been better? Nobody <nobody@nowhere.com> - 2012-07-23 10:37 +0100
      Re: Restricted unsigned integer range would have been better? Andre <lodwig@pathme.de> - 2012-07-23 11:46 +0200
    Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-23 11:33 +0100
      Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-23 23:48 -0600
        Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-24 10:43 +0100
          Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-24 02:58 -0700
            Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-24 12:04 +0100
              Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-24 05:32 -0700
                Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-24 14:20 +0100
                  Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-24 18:41 +0100
                  Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-24 12:37 -0700
              Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 16:15 -0600
          Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 16:05 -0600
            Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-24 23:28 -0700
              Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 01:13 -0600
                Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-25 01:26 -0700
                  Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 05:43 -0600
        Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-24 15:10 +0200
          Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 16:23 -0600
            Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-24 23:40 -0700
              Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 01:32 -0600
                Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-25 01:29 -0700
                  Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 05:45 -0600
                    Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-25 12:35 -0700
                      Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-26 00:12 -0600
                        Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-26 01:42 -0700
            Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-25 09:31 +0200
              Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 06:28 -0600
                Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-25 16:28 +0200
                  Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-25 17:17 +0100
                    Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-26 12:07 +0200
                      Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-26 14:06 +0100
                        Re: Restricted unsigned integer range would have been better? James Kuyper <jameskuyper@verizon.net> - 2012-07-26 09:45 -0400
                        Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-30 09:01 +0200
                  Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-26 00:09 -0600
                    Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-26 00:52 -0700
    Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-07-26 20:35 -0400
      Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-26 22:35 -0600
        Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-07-27 09:19 -0400
          Re: Restricted unsigned integer range would have been better? Les Cargill <lcargill99@comcast.com> - 2012-07-27 12:51 -0500
            Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-27 16:19 -0700
              Re: Restricted unsigned integer range would have been better? Les Cargill <lcargill99@comcast.com> - 2012-07-27 18:47 -0500
                Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-30 09:10 +0200
                  Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-07-31 17:26 -1000
                    Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-08-01 00:18 -0400
                      Re: Restricted unsigned integer range would have been better? "io_x" <a@b.c.invalid> - 2012-08-01 10:19 +0200
                      Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-08-01 10:09 +0200
                        Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-01 12:51 +0100
                          Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-08-01 08:18 -0400
                            Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-01 14:22 +0100
                              Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-08-01 09:57 -0400
                                Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-08-01 11:35 -0400
                      Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 11:43 -0700
                        Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-09-08 10:13 -0400
                          Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-09-22 23:39 -0700
                            Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-09-22 23:45 -0700
                              Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 13:52 -0800
                            Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 13:45 -0800
                              Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-12-17 19:51 -0500
                              Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-12-28 11:11 -0800
                                Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-29 11:31 -0800
                                  Re: Restricted unsigned integer range would have been better? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-29 23:59 +0000
                                    Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-02 10:01 -0800
                                      Re: Restricted unsigned integer range would have been better? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-01-05 12:00 +0200
                                  Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2013-01-02 13:07 -0800
                                    Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-03 12:10 -0800
                                    Re: Restricted unsigned integer range would have been better? James Kuyper <jameskuyper@verizon.net> - 2013-01-05 12:26 -0500
                        Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-09-22 23:35 -0700
                          Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 14:02 -0800
                    Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-08-01 10:06 +0200
                      Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-01 12:46 +0100
                        Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-08-02 08:19 -1000
                      Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-08-02 08:17 -1000
                        Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-08-03 08:04 +0200
                      Re: Restricted unsigned integer range would have been better? "io_x" <a@b.c.invalid> - 2012-08-03 09:40 +0200
              Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-27 22:27 -0600
                Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-28 01:31 -0700
                Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-28 10:52 +0100
              Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-28 03:31 -0700
            Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-07-28 00:05 -0400
              Re: Restricted unsigned integer range would have been better? Les Cargill <lcargill99@comcast.com> - 2012-07-27 23:22 -0500
              Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-27 22:35 -0600
                Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-04 08:43 -0700
                  Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-08-04 16:40 -0700
                    Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:58 -0600
                      Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-08-04 23:10 -0700
                        Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-05 01:16 -0600
                          Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-08-05 02:25 -0700
                            Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-05 03:35 -0600
                              Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-08-05 12:16 -0700
                                Re: Restricted unsigned integer range would have been better? gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-05 19:56 +0000
                                  Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-06 01:12 -0600
                                Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-06 01:07 -0600
                        Re: Restricted unsigned integer range would have been better? gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-05 13:33 +0000
                          Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-06 01:13 -0600
                  Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:54 -0600

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

#24041

On 01/08/2012 05:26, Philip Lantz wrote:
> David Brown wrote:
>> Les Cargill wrote:
>>> Keith Thompson wrote:
>>>> Les Cargill writes:
>>>>> Type conversions must be made explicit.
>>>>
>>>> I presume that's meant as advice, not a language rule.
>>>
>>> Sorry - yes, it's advice.
>>
>> Good advice.
>>
>> For my work, it is more than advice - it is a style rule, and I enforce
>> it with compiler warnings (-Wconversion -Wsign-conversion in gcc).
>
> Do you really? Would you use casts in situations like these?

There are some conversions that are done automatically for which it 
doesn't make sense to have them explicit.  In particular, promotions 
that cannot change the value don't need to be explicit (such as 
assigning an uint16_t to a uint32_t variable).

>    1. char c = 'x';

Both the reader and the compiler can see that while this is technically 
an integer constant assigned to a char variable, there is no risk of 
losing data.

The key point here is that the code should be absolutely clear to the 
reader, and the reader's interpretation should match the compiler's 
interpretation.  Explicit casts are needed if there could be any doubt.

>    2. int *p = malloc(N * sizeof *p);

First off, I almost never use malloc.  I write software for embedded 
systems, mostly fairly small systems, and I haven't needed general 
dynamic memory more than a couple of times in 20 years.  Occasionally 
I'll have a more specialised dynamic memory system, but otherwise almost 
everything is static (or on the stack).

I would write that as :

	int* p = (int*) malloc(N * sizeof(*p));

I prefer to make casts from void* explicit.  It also improves 
compatibility with C++, for portability of the code.

Again, there is another hidden cast - N (which is presumably an integer 
of some sort) will be promoted to size_t before the multiplication.  And 
again, I don't see a need to cast it here.

>    3. free(p);

No need to cast that one, unless the pointer type is qualified (volatile 
or const) - in which case I /would/ want an explicit cast.

>    4. printf("%c\n", c);

Again, I seldom use printf (though it does happen occasionally, more 
often in the snprintf variation).  And I use "-Wformat" to check arguments.

I would not bother casting the result to (void), unless I wanted to 
specifically indicate that the function's return value is normally 
important but that I was ignoring it at the time.

>    5. while (*s != '\0')
>           n = n * 10 + (*s - '0');

I don't see a need for casting here either, as all the implicit casting 
is clear and safe (assuming, of course, that s points to a string of 
digits and we already know that they are valid).  I might add extra code 
to limit the loop or check for overflows, depending on the context.

I would, however, include brackets around the loop contents.

>
> I would find them to be undesirable clutter.
>

So I would write:

char c = 'x';
int *p = (int*) malloc(N * sizeof(*p));
free(p);
printf("%c\n", c);
while (*s != '\0') {
	n = n * 10 + (*s - '0');
}

Of course, you picked examples here where explicit casting adds little, 
and even someone as fussy as me would omit them.  In my real-world code, 
it is not uncommon to see casts between signed or unsigned types, or 
types of different sizes, where other programmers would likely omit them.

The key point, as I said above, is to make sure there is no ambiguity 
for either humans or compilers.  But avoiding "undesirable clutter" is 
also important - anything that makes the code harder to read is, of 
course, a bad idea.

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

#24046

David Brown <david@westcontrol.removethisbit.com> writes:

> On 01/08/2012 05:26, Philip Lantz wrote:
<snip>
>> Do you really? Would you use casts in situations like these?
<snip>
>>    4. printf("%c\n", c);
>
> Again, I seldom use printf (though it does happen occasionally, more
> often in the snprintf variation).  And I use "-Wformat" to check
> arguments.
>
> I would not bother casting the result to (void), unless I wanted to
> specifically indicate that the function's return value is normally
> important but that I was ignoring it at the time.

Philip Lantz might be referring to the implicit char to int default
argument promotion that occurs in the ... argument position of vararg
function calls, but I don't think that would affect matter.  It follows
the pattern of implicit conversions that you don't object to.

<snip>
-- 
Ben.

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

#24142

Ben Bacarisse wrote:
> 
> David Brown <david@westcontrol.removethisbit.com> writes:
> 
> > On 01/08/2012 05:26, Philip Lantz wrote:
> <snip>
> >> Do you really? Would you use casts in situations like these?
> <snip>
> >>    4. printf("%c\n", c);
> >
> > Again, I seldom use printf (though it does happen occasionally, more
> > often in the snprintf variation).  And I use "-Wformat" to check
> > arguments.
> >
> > I would not bother casting the result to (void), unless I wanted to
> > specifically indicate that the function's return value is normally
> > important but that I was ignoring it at the time.
> 
> Philip Lantz might be referring to the implicit char to int default
> argument promotion that occurs in the ... argument position of vararg
> function calls

I was.

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

#24141

David Brown wrote:
> 
> On 01/08/2012 05:26, Philip Lantz wrote:
> > David Brown wrote:
> >> Les Cargill wrote:
> >>> Keith Thompson wrote:
> >>>> Les Cargill writes:
> >>>>> Type conversions must be made explicit.
> >>>>
> >>>> I presume that's meant as advice, not a language rule.
> >>>
> >>> Sorry - yes, it's advice.
> >>
> >> Good advice.
> >>
> >> For my work, it is more than advice - it is a style rule, and I enforce
> >> it with compiler warnings (-Wconversion -Wsign-conversion in gcc).
> >
> > Do you really? Would you use casts in situations like these?
> 
> There are some conversions that are done automatically for which it 
> doesn't make sense to have them explicit.  In particular, promotions 
> that cannot change the value don't need to be explicit (such as 
> assigning an uint16_t to a uint32_t variable).
> 
> >    1. char c = 'x';
> 
> Both the reader and the compiler can see that while this is technically 
> an integer constant assigned to a char variable, there is no risk of 
> losing data.
> 
> The key point here is that the code should be absolutely clear to the 
> reader, and the reader's interpretation should match the compiler's 
> interpretation.  Explicit casts are needed if there could be any doubt.
> 
> >    2. int *p = malloc(N * sizeof *p);
> 
> First off, I almost never use malloc.  I write software for embedded 
> systems, mostly fairly small systems, and I haven't needed general 
> dynamic memory more than a couple of times in 20 years.  Occasionally 
> I'll have a more specialised dynamic memory system, but otherwise almost 
> everything is static (or on the stack).
> 
> I would write that as :
> 
> 	int* p = (int*) malloc(N * sizeof(*p));
> 
> I prefer to make casts from void* explicit.  It also improves 
> compatibility with C++, for portability of the code.
> 
> Again, there is another hidden cast - N (which is presumably an integer 
> of some sort) will be promoted to size_t before the multiplication.  And 
> again, I don't see a need to cast it here.
> 
> >    3. free(p);
> 
> No need to cast that one, unless the pointer type is qualified (volatile 
> or const) - in which case I /would/ want an explicit cast.
> 
> >    4. printf("%c\n", c);
> 
> Again, I seldom use printf (though it does happen occasionally, more 
> often in the snprintf variation).  And I use "-Wformat" to check arguments.
> 
> I would not bother casting the result to (void), unless I wanted to 
> specifically indicate that the function's return value is normally 
> important but that I was ignoring it at the time.
> 
> >    5. while (*s != '\0')
> >           n = n * 10 + (*s - '0');
> 
> I don't see a need for casting here either, as all the implicit casting 
> is clear and safe (assuming, of course, that s points to a string of 
> digits and we already know that they are valid).  I might add extra code 
> to limit the loop or check for overflows, depending on the context.
> 
> I would, however, include brackets around the loop contents.
> 
> >
> > I would find them to be undesirable clutter.
> >
> 
> So I would write:
> 
> char c = 'x';
> int *p = (int*) malloc(N * sizeof(*p));
> free(p);
> printf("%c\n", c);
> while (*s != '\0') {
> 	n = n * 10 + (*s - '0');
> }
> 
> Of course, you picked examples here where explicit casting adds little, 
> and even someone as fussy as me would omit them.  In my real-world code, 
> it is not uncommon to see casts between signed or unsigned types, or 
> types of different sizes, where other programmers would likely omit them.

Thanks for your clarifications. I think we are very nearly in complete 
agreement. I did, of course, pick examples where I think it is clear the 
casts are pointless, plus the malloc case, where the cast is anathema to 
some in this group.

(I almost put brackets around the loop body, just to avoid the 
distraction, because I *knew* you would comment on it :-), but I left 
them out for brevity.)

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

#24160

On 02/08/2012 20:17, Philip Lantz wrote:
> David Brown wrote:
>>
>> On 01/08/2012 05:26, Philip Lantz wrote:
>>> David Brown wrote:
>>>> Les Cargill wrote:
>>>>> Keith Thompson wrote:
>>>>>> Les Cargill writes:
>>>>>>> Type conversions must be made explicit.
>>>>>>
>>>>>> I presume that's meant as advice, not a language rule.
>>>>>
>>>>> Sorry - yes, it's advice.
>>>>
>>>> Good advice.
>>>>
>>>> For my work, it is more than advice - it is a style rule, and I enforce
>>>> it with compiler warnings (-Wconversion -Wsign-conversion in gcc).
>>>
>>> Do you really? Would you use casts in situations like these?
>>
>> There are some conversions that are done automatically for which it
>> doesn't make sense to have them explicit.  In particular, promotions
>> that cannot change the value don't need to be explicit (such as
>> assigning an uint16_t to a uint32_t variable).
>>
>>>     1. char c = 'x';
>>
>> Both the reader and the compiler can see that while this is technically
>> an integer constant assigned to a char variable, there is no risk of
>> losing data.
>>
>> The key point here is that the code should be absolutely clear to the
>> reader, and the reader's interpretation should match the compiler's
>> interpretation.  Explicit casts are needed if there could be any doubt.
>>
>>>     2. int *p = malloc(N * sizeof *p);
>>
>> First off, I almost never use malloc.  I write software for embedded
>> systems, mostly fairly small systems, and I haven't needed general
>> dynamic memory more than a couple of times in 20 years.  Occasionally
>> I'll have a more specialised dynamic memory system, but otherwise almost
>> everything is static (or on the stack).
>>
>> I would write that as :
>>
>> 	int* p = (int*) malloc(N * sizeof(*p));
>>
>> I prefer to make casts from void* explicit.  It also improves
>> compatibility with C++, for portability of the code.
>>
>> Again, there is another hidden cast - N (which is presumably an integer
>> of some sort) will be promoted to size_t before the multiplication.  And
>> again, I don't see a need to cast it here.
>>
>>>     3. free(p);
>>
>> No need to cast that one, unless the pointer type is qualified (volatile
>> or const) - in which case I /would/ want an explicit cast.
>>
>>>     4. printf("%c\n", c);
>>
>> Again, I seldom use printf (though it does happen occasionally, more
>> often in the snprintf variation).  And I use "-Wformat" to check arguments.
>>
>> I would not bother casting the result to (void), unless I wanted to
>> specifically indicate that the function's return value is normally
>> important but that I was ignoring it at the time.
>>
>>>     5. while (*s != '\0')
>>>            n = n * 10 + (*s - '0');
>>
>> I don't see a need for casting here either, as all the implicit casting
>> is clear and safe (assuming, of course, that s points to a string of
>> digits and we already know that they are valid).  I might add extra code
>> to limit the loop or check for overflows, depending on the context.
>>
>> I would, however, include brackets around the loop contents.
>>
>>>
>>> I would find them to be undesirable clutter.
>>>
>>
>> So I would write:
>>
>> char c = 'x';
>> int *p = (int*) malloc(N * sizeof(*p));
>> free(p);
>> printf("%c\n", c);
>> while (*s != '\0') {
>> 	n = n * 10 + (*s - '0');
>> }
>>
>> Of course, you picked examples here where explicit casting adds little,
>> and even someone as fussy as me would omit them.  In my real-world code,
>> it is not uncommon to see casts between signed or unsigned types, or
>> types of different sizes, where other programmers would likely omit them.
>
> Thanks for your clarifications. I think we are very nearly in complete
> agreement. I did, of course, pick examples where I think it is clear the
> casts are pointless, plus the malloc case, where the cast is anathema to
> some in this group.
>
> (I almost put brackets around the loop body, just to avoid the
> distraction, because I *knew* you would comment on it :-), but I left
> them out for brevity.)
>

I could smell that the loop was a trap, but I couldn't help falling for 
it!  (Did you notice that I also added brackets around the argument to 
sizeof?)

I think we do agree entirely on the principle of readable code.  But in 
my work, embedded programming, I am regularly mixing signed and unsigned 
types, as well as types of different sizes, on targets with varying 
processor sizes - so I prefer to be a lot more explicit about casts and 
conversions than most programmers.

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

#24161

"David Brown" <david@westcontrol.removethisbit.com> ha scritto nel messaggio
news:P4Odncnoya77eIXNnZ2dnUVZ8iSdnZ2d@lyse.net...
> On 01/08/2012 05:26, Philip Lantz wrote:
>> David Brown wrote:
>>> Les Cargill wrote:
>>>> Keith Thompson wrote:
>>>>> Les Cargill writes:
>>>>>> Type conversions must be made explicit.
>>>>>
>>>>> I presume that's meant as advice, not a language rule.
>>>>
>>>> Sorry - yes, it's advice.
>>>
>>> Good advice.
>>    5. while (*s != '\0')
>>           n = n * 10 + (*s - '0');
>
> So I would write:
>
> char c = 'x';
> int *p = (int*) malloc(N * sizeof(*p));
> free(p);
> printf("%c\n", c);
> while (*s != '\0') {
> n = n * 10 + (*s - '0');

i will never write something as above...
if  s point to one ascii string
i write it in assembly but if i have to write it in C i whould write
something as

u32  c;
u32  n;
u8   *stop;

n= 0; c =0;  stop=s;
while(3)
   {c=*s; vv=v;
    if(c<'0' || c>'9')  break;
    c-='0'
    n = n*10+c;
    // check if overflow n
    ++s;
    // check if overflow s
   }
if(stop==s) return  -1;
else        return   n;

result in the range [0, (u32)-1)
error (u32)-1
no overflow detection for too big numbers...

where u32 is unsigned 32 bit.
the problem is not
    write it n= n*10+ (c-'0');
 or write it n= n*10+  c-'0' ;  etc
because if not '0'<=*s<='9' the result is wrong
for definition for both cases

> }
>
> Of course, you picked examples here where explicit casting adds little, and
> even someone as fussy as me would omit them.  In my real-world code, it is not
> uncommon to see casts between signed or unsigned types, or types of different
> sizes, where other programmers would likely omit them.
>
> The key point, as I said above, is to make sure there is no ambiguity for
> either humans or compilers.  But avoiding "undesirable clutter" is also
> important - anything that makes the code harder to read is, of course, a bad
> idea.

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

#23838

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnpq7g6bco.fsf@nuthaus.mib.org...
> Les Cargill <lcargill99@comcast.com> writes:
>> pete wrote:
> [...]
>>> I think I see what you mean.
>>> C is a primative tool.
>>> As is typical of primative tools,
>>> study and practice goes a long way towards efficacy.
>>> Prgrammers who like C,
>>> tend to like the primitiveness of it.
>>
>> This is modestly silly :) C is still a *high level language*,
>> and there's very little you cannot do with it.
>
> I wouldn't call C a high level language, but that depends entirely
> on how you define the phrase "high level".
>
> It's high level in the sense that C programs specify behavior,
> not CPU instructions.  Of the languages that are "high level" in
> that sense, I'd say that C is just about the lowest-level language
> in common use.
>

High-level language: any language above assembly languages.
Low-level language: assembly languages and below.

Why? Because the low-level languages are CPU-ish: the elements of 
programming are instructions or even lower, op codes. High-level languages 
abstract that away, so there is the division line, at least traditionally 
(as I learned it anyway and still ascribe to that because it makes good 
sense). 

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

#23841

"Ansel" <tinker454@trytospammenowloser.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnpq7g6bco.fsf@nuthaus.mib.org...
>> Les Cargill <lcargill99@comcast.com> writes:
[...]
>>> This is modestly silly :) C is still a *high level language*,
>>> and there's very little you cannot do with it.
>>
>> I wouldn't call C a high level language, but that depends entirely
>> on how you define the phrase "high level".
>>
>> It's high level in the sense that C programs specify behavior,
>> not CPU instructions.  Of the languages that are "high level" in
>> that sense, I'd say that C is just about the lowest-level language
>> in common use.
>
> High-level language: any language above assembly languages.
> Low-level language: assembly languages and below.

Those are certainly valid definitions of those terms.

But I don't think they're widely accepted.  Most programmers would
probably say that Ada, for example, is a high-level language and C is a
low-level language.  That's certainly true in a relative sense; C is a
lower-level language that Ada.

(Substitute your favorite higher-level-than-C language for Ada if you
like.)

> Why? Because the low-level languages are CPU-ish: the elements of 
> programming are instructions or even lower, op codes. High-level languages 
> abstract that away, so there is the division line, at least traditionally 
> (as I learned it anyway and still ascribe to that because it makes good 
> sense). 

Yes, there's a very strong dividing line between assembly languages and
non-assembly languages, and C is on the high-level side of that line.
But common usage doesn't necessarily follow that logic.

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

#23842

"Ansel" <tinker454@trytospammenowloser.com> wrote in message 
news:juvpqq$c8k$1@speranza.aioe.org...
>
> "Keith Thompson" <kst-u@mib.org> wrote in message

>> It's high level in the sense that C programs specify behavior,
>> not CPU instructions.  Of the languages that are "high level" in
>> that sense, I'd say that C is just about the lowest-level language
>> in common use.
>>
>
> High-level language: any language above assembly languages.
> Low-level language: assembly languages and below.
>
> Why? Because the low-level languages are CPU-ish: the elements of 
> programming are instructions or even lower, op codes. High-level languages 
> abstract that away, so there is the division line, at least traditionally 
> (as I learned it anyway and still ascribe to that because it makes good 
> sense).

A low-level language would be a specific assembler, a machine oriented 
language, or a 'high-level' assembler, which latter might look, deceptively, 
like high-level, but they are cruder in their capabilities.

But as a high-level language, C is near the bottom of the range. I would 
classify it more from it's data handling:

o Static data types always known at compile-time
o Primitive types based around likely machine types
o Collections (arrays, structs) of types which are always of fixed bounds 
known at compile-time
o Always explicit memory management
o Always explicit pointer handling (although some constructions look 
implicit)

C, arguably, has dynamic (and perhaps flexible) arrays, but handled 
explicitly, and things such as VLAs, which are interesting but not enough to 
raise it to the next tier! (Pass a VLA to a function, and you still just 
have a bare pointer with no idea what length it is.)

For many people, this is enough: if using C to implement a higher-level 
language for example, you don't want C's own capabilities to get in the way.

Syntax is less important: more higher-level syntax can be added to C, but if 
it's data-handling is the same, then it's still really at the same level 
(but, it wouldn't hurt either...).

-- 
Bartc 

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

#23843

בתאריך יום שבת, 28 ביולי 2012 00:19:35 UTC+1, מאת Keith Thompson:
> Les Cargill <lcargill99@comcast.com> writes:
> 
> I wouldn't call C a high level language, but that depends entirely 
> on how you define the phrase "high level".
> 
A high level language is one which makes it easy to perform complex operations with a minimu of code. Usually this comes at a cost of making it difficult to perform simple operations efficiently, and often the complex operations are only a subset of all programming operations.

For instance R has powerful operations for reading in 2 dimensional data tables, subjecting them to statictical analysis, and displaying the results in graphs. However whilst it's possible to get it to play space invaders, it's very difficult. It's also quite hard to get it do things like 3d Fourier transforms. But it's relatively easy to code a 3d Fourier transform in C, then provide a R-callable interface to the code.

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

#23835

Les Cargill wrote:

> C is still a *high level language*,

K&R Introduction says "C is a relatively 'low level' language."

-- 
pete

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

#23837

pete wrote:
> Les Cargill wrote:
>
>> C is still a *high level language*,
>
> K&R Introduction says "C is a relatively 'low level' language."
>

Yes it does. Yes it does. They were modest in their aspirations.

--
Les Cargill

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

#23839

"pete" <pfiland@mindspring.com> wrote in message 
news:50136504.5CAB@mindspring.com...
> Les Cargill wrote:
>
>> C is still a *high level language*,
>
> K&R Introduction says "C is a relatively 'low level' language."
>

That is true if the set in which it is being compared is comprised of only 
high-level languages. Relative to most of that set, C is indeed relatively 
low-level. Broaden the scope of  the comparison set by throwing assembly 
language into it and then C is clearly high-level. The lowest of the high 
maybe, but definitely high. 

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

#24212

בתאריך יום שבת, 28 ביולי 2012 05:35:49 UTC+1, מאת Ansel:
> "pete" <pfiland@mindspring.com> wrote in message 
>
> That is true if the set in which it is being compared is comprised of only 
> high-level languages. Relative to most of that set, C is indeed relatively 
> low-level. Broaden the scope of  the comparison set by throwing assembly 
> language into it and then C is clearly high-level. The lowest of the high 
> maybe, but definitely high.
>
Really the answer depends on your librsries. C without a library isn't much higher-level than assembly language. It's portable, it has support for floating point, structuers, strings, and pointer management, and it does your subroutine bookkeeping for you. But that's only a thin layer on top of assembler.

C with a library can have all sorts of sophisticated capabilites. The thin layer on top of assembler is an important thin layer, because it enables you to string together library calls very easily.
  

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

#24228

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> Really the answer depends on your librsries. C without a library isn't
> much higher-level than assembly language. It's portable, it has
> support for floating point, structuers, strings, and pointer
> management, and it does your subroutine bookkeeping for you. But
> that's only a thin layer on top of assembler.
[...]

I don't consider it a thin layer.  The big difference is that assembly
language programs specify CPU instructions, while C programs specify
behavior.

(And Malcolm, can you please find a way to keep your lines down to 72
columns or so?  If you're posting through Google Groups, you can always
copy-and-paste your article to a text editor and back before posting.)

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

#24240

Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> [...]
>> Really the answer depends on your librsries. C without a library
>> isn't much higher-level than assembly language. It's portable, it has
>> support for floating point, structuers, strings, and pointer
>> management, and it does your subroutine bookkeeping for you. But
>> that's only a thin layer on top of assembler.
> [...]
>
> I don't consider it a thin layer.  The big difference is that assembly
> language programs specify CPU instructions, while C programs specify
> behavior.
>

That is a lame post. "behavior"? Assembly instructions do not cause 
behavior? What was wrong with my definition that had in it that C abstracts 
the CPU instructions? 

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

#24242

"Ansel" <tinker454@trytospammenowloser.com> writes:
> Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> [...]
>>> Really the answer depends on your librsries. C without a library
>>> isn't much higher-level than assembly language. It's portable, it has
>>> support for floating point, structuers, strings, and pointer
>>> management, and it does your subroutine bookkeeping for you. But
>>> that's only a thin layer on top of assembler.
>> [...]
>>
>> I don't consider it a thin layer.  The big difference is that assembly
>> language programs specify CPU instructions, while C programs specify
>> behavior.
>
> That is a lame post.

Try being less rude.

>                      "behavior"? Assembly instructions do not cause 
> behavior?

Yes, assembly instructions cause behavior.  More precisely, assembly
instructions specify machine code instructions, which cause behavior.

>           What was wrong with my definition that had in it that C abstracts 
> the CPU instructions? 

What definition is that?  What term were you defining?

C does so only in the same sense that all programming languages above
the level of assembly do so.

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

#24245

Keith Thompson wrote:
> "Ansel" <tinker454@trytospammenowloser.com> writes:
>> Keith Thompson wrote:
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>> [...]
>>>> Really the answer depends on your librsries. C without a library
>>>> isn't much higher-level than assembly language. It's portable, it
>>>> has support for floating point, structuers, strings, and pointer
>>>> management, and it does your subroutine bookkeeping for you. But
>>>> that's only a thin layer on top of assembler.
>>> [...]
>>>
>>> I don't consider it a thin layer.  The big difference is that
>>> assembly language programs specify CPU instructions, while C
>>> programs specify behavior.
>>
>> That is a lame post.
>
> Try being less rude.

And pander to your institution? Ain't gonna happen.

>
>>                      "behavior"? Assembly instructions do not cause
>> behavior?
>
> Yes, assembly instructions cause behavior.  More precisely,

And you are "keen" on being "more precise". Because you think that is a 
winning thing. "checkmate", right?

> assembly
> instructions specify machine code instructions, which cause behavior.

You did not have to spout out loud your reflection.

>
>>           What was wrong with my definition that had in it that C
>> abstracts the CPU instructions?
>
> What definition is that?  What term were you defining?

What is not obvious to you? I don't want to interact with you more than I 
have to. I said: "C abstracts the 'CPU level'". Don't dare try to take me 
back to the 1960's, cuz I may get mad.

>
> C does so only in the same sense that all programming languages above
> the level of assembly do so.

"hello". Didn't I say that the dividing line between "high" and "low" level 
was exactly that? 

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

#24251

"Ansel" <tinker454@trytospammenowloser.com> writes:
> Keith Thompson wrote:
>> "Ansel" <tinker454@trytospammenowloser.com> writes:
[...]
>>> That is a lame post.
>>
>> Try being less rude.
>
> And pander to your institution? Ain't gonna happen.

Try harder.

[snip]

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

#24253

Keith Thompson wrote:
> "Ansel" <tinker454@trytospammenowloser.com> writes:
>> Keith Thompson wrote:
>>> "Ansel" <tinker454@trytospammenowloser.com> writes:
> [...]
>>>> That is a lame post.
>>>
>>> Try being less rude.
>>
>> And pander to your institution? Ain't gonna happen.
>
> Try harder.
>
> [snip]

I don't need to do that. I just remember. You are out of the picture too. 
Been for a long time. 

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

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

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

csiph-web