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

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

Array allocated on stack or heap

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

Contents

  Array allocated on stack or heap Prashant Shah <pshah.mumbai@gmail.com> - 2017-03-16 22:58 -0700
    Re: Array allocated on stack or heap Barry Schwarz <schwarzb@dqel.com> - 2017-03-16 23:57 -0700
      Re: Array allocated on stack or heap Mark Storkamp <mstorkamp@yahoo.com> - 2017-03-17 12:44 -0500
        Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 11:26 -0700
          Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 20:38 +0100
            Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 16:08 -0400
              Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:03 +0100
                Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 20:54 -0400
    Re: Array allocated on stack or heap John Bode <jfbode1029@gmail.com> - 2017-03-17 12:15 -0700
      Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-17 20:22 +0100
      Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 20:45 +0100
        Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-17 12:59 -0700
        Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-17 21:01 +0100
          Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:12 +0100
            Re: Array allocated on stack or heap jameskuyper@verizon.net - 2017-03-17 16:25 -0700
              Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 17:08 -0700
                Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-17 17:37 -0700
            Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 12:30 +0100
              Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 12:12 +0000
                Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:52 +0100
                  Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 16:51 +0000
                    Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 10:44 +0100
                      Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-20 12:01 +0000
                        Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-20 06:02 -0700
                          Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-20 14:54 +0100
                            Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-20 07:28 -0700
                              Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 16:43 +0100
                              Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-20 09:02 -0700
                                Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 10:11 +0100
                                  Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 02:48 -0700
                                    Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-21 08:19 -0700
                                  Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-21 08:17 -0700
                                    Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-21 09:06 -0700
                                    Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 17:32 +0100
                              Re: Array allocated on stack or heap Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:14 -0500
                                Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-25 16:05 -0700
                                  Re: Array allocated on stack or heap Les Cargill <lcargill99@comcast.com> - 2017-03-25 23:53 -0500
                                    Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-26 12:30 +0100
                                      Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-26 14:09 -0700
                                        Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-26 22:17 +0100
                                      Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-26 21:52 -0500
                                        Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-27 13:06 +0100
                                          Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-27 10:10 -0700
                                          Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 15:56 -0500
                                            Re: Array allocated on stack or heap bartc <bc@freeuk.com> - 2017-03-27 22:48 +0100
                                              Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 19:58 -0500
                          Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-20 14:56 +0100
                        Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 15:34 +0100
                          Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 09:28 -0700
                            Re: Array allocated on stack or heap bart4858@gmail.com - 2017-03-20 13:05 -0700
                              Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 13:53 -0700
                                Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 14:26 -0700
                                Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-20 22:24 +0000
                                  Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 15:44 -0700
                                    Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 02:44 -0700
                                  Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 11:15 +0100
                                    Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-21 11:12 +0000
                                      Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 04:23 -0700
                                      Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 13:13 +0000
                                        Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-21 13:38 +0000
                                          Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 15:33 +0100
                                            Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 07:38 -0700
                                          Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 07:35 -0700
                                            Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 15:09 +0000
                Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:05 +0000
                  Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 13:27 +0000
                  Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:26 +0100
                    Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:34 +0000
                      Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:35 +0100
                  Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:36 +0000
                    Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 14:00 +0000
                      Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 19:00 +0000
                        Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 19:24 +0000
                          Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 08:45 +1300
                            Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-19 14:32 -0700
                              Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 16:16 +1300
                                Re: Array allocated on stack or heap Gareth Owen <gwowen@gmail.com> - 2017-03-20 18:58 +0000
                              Re: Array allocated on stack or heap raltbos@xs4all.nl (Richard Bos) - 2017-03-24 09:17 +0000
                          Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 20:50 +0000
                Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:10 +0100
                  Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 13:38 +0000
                    Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:49 +0100
                      Re: Array allocated on stack or heap luser droog <luser.droog@gmail.com> - 2017-03-20 07:59 -0700
                Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-19 10:57 -0400
                  Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 16:14 +0000
                    Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-19 15:53 -0400
                      Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 20:37 +0000
                        Re: Array allocated on stack or heap Jean-Marc Bourguet <jm@bourguet.org> - 2017-03-19 23:09 +0100
                          Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 22:38 +0000
                            Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-19 16:21 -0700
                            Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 16:18 +1300
                          Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 11:06 +0100
                    Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 11:00 +0100
                Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-19 08:53 -0700
        Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 16:11 -0400
        Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 13:35 -0700
          Re: Array allocated on stack or heap Chad <cdalten@gmail.com> - 2017-03-17 14:00 -0700
            Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 23:57 +0100
              Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-18 12:42 +1300
                Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:45 +0100
              Re: Array allocated on stack or heap Chad <cdalten@gmail.com> - 2017-03-18 14:17 -0700
                Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-19 19:21 +0100
                  Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-19 15:00 -0700
                    Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 22:16 +0000
                      Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-19 23:57 +0100
                        Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-19 16:15 -0700
                        Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 12:24 +0100
                      Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-20 13:24 +0000
              Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:21 +0100
        Re: Array allocated on stack or heap John Bode <jfbode1029@gmail.com> - 2017-03-17 14:30 -0700
          Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 23:59 +0100
          Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 21:02 -0400
          Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:26 +0100

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

#106498

On 19/03/2017 12:52, David Brown wrote:
> On 19/03/17 13:12, BartC wrote:

>> In Java, the types {byte, short, int, long} have widths {8, 16, 32, 64}.
>>
>> In C#, the types {sbyte, short, int, long} have widths {8, 16, 32, 64}.
>>
>> In Rust, they seem to be {i8, i16, i32, i64} (you can guess the widths).
>>
>> In Go, they are {int8, int16, int32, int64}.

>> Plus the fact that all types are signed, except for char which may be
>> signed OR unsigned, a fact you might not even know.
>
> If you care whether "char" is signed or unsigned, you have been careless
> in your coding.

Do you mean that someone shouldn't need to care whether 'int' is signed 
or 'unsigned' either?

It can make a significant difference. Or do you mean that 'signed char' 
or 'unsigned char' should be used where it does matter?

In which case it would save a lot of typing is someone knew once and for 
all if 'char' was signed or not.

However, even using 'signed char' or 'unsigned char' can give problems:

    #include <string.h>

    int main(void) {
       unsigned char *s;
       signed char *t;

       strlen(s);
       strlen(t);
    }

With Digital Mars' C, neither of those calls will work:

------------------------------
strlen(s);
         ^
C:\c\c.c(11) : Error: need explicit cast for function parameter 1 to get
from: unsigned char *
to  : char const *
strlen(t);
         ^
C:\c\c.c(12) : Error: need explicit cast for function parameter 1 to get
from: signed char *
to  : char const *
------------------------------

Maybe it's a just a peculiarity of that compiler, but it does seem 
extraordinary that char is compatible with neither signed or unsigned 
char! Or is this some sort of quantum effect where not even the compiler 
itself actually knows the sign of 'char', so it's not able to say one 
way or the other?

Anyway, I doubt such issues come up with any of those other languages I 
listed.

>>
>> Anyone notice an obvious way that this mess could be tidied up?
>
> Yes - you could introduce some size-specific types so that people who
> needed tighter specifications for their integer types could say exactly
> what they wanted.

That's not tidying it up. It's brushing it under the carpet. Or rather, 
laying a new carpet on top of the old.

> Most uses of "char" are for storing letters or characters, or for
> abstract byte storage - the signedness does not matter.

You've never had to compare one character with another? Anyway 'char' is 
extensively used in place of a proper 'byte' type. Since byte values 
tend to be thought of unsigned 8-bit quantities, it seems perverse to 
use a 'char' that is either signed, or that you don't know whether it is 
signed or unsigned. And if you define byte as 'unsigned char' then you 
may run into the problems of having THREE incompatible char types as I 
showed above!

Sorry, but it's still a mess.

-- 
bartc

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

#106539

On 19/03/17 17:51, BartC wrote:
> On 19/03/2017 12:52, David Brown wrote:
>> On 19/03/17 13:12, BartC wrote:
> 
>>> In Java, the types {byte, short, int, long} have widths {8, 16, 32, 64}.
>>>
>>> In C#, the types {sbyte, short, int, long} have widths {8, 16, 32, 64}.
>>>
>>> In Rust, they seem to be {i8, i16, i32, i64} (you can guess the widths).
>>>
>>> In Go, they are {int8, int16, int32, int64}.
> 
>>> Plus the fact that all types are signed, except for char which may be
>>> signed OR unsigned, a fact you might not even know.
>>
>> If you care whether "char" is signed or unsigned, you have been careless
>> in your coding.
> 
> Do you mean that someone shouldn't need to care whether 'int' is signed
> or 'unsigned' either?

No.  If I had meant that, I would have written that.

"int" is signed - that is /always/ the case.  If you want an unsigned
equivalent type, "unsigned int" is there for you.

But plain "char" may be signed and may be unsigned - it is
implementation dependent.  There have been cases of compilers on the
same platform changing that choice between versions.  There is never,
AFAIK, a reason why one would want to know or use the signedness of
plain char - because there are perfectly good, clear, simple
alternatives "signed char" and "unsigned char" that give you /exactly/
what you want.

> 
> It can make a significant difference. Or do you mean that 'signed char'
> or 'unsigned char' should be used where it does matter?

Yes.

> 
> In which case it would save a lot of typing is someone knew once and for
> all if 'char' was signed or not.

No, it would /not/ save a lot of typing.  It is very rare that the
signedness of char actually matters.  And in most code where it would be
relevant, you are far better using "uint8_t" and "int8_t".  (If the code
is to be portable to devices with CHAR_BIT > 8, you would use different
typedefs like uint_least8_t.)

> 
> However, even using 'signed char' or 'unsigned char' can give problems:
> 
>    #include <string.h>
> 
>    int main(void) {
>       unsigned char *s;
>       signed char *t;
> 
>       strlen(s);
>       strlen(t);
>    }

"strlen" is a function on strings - sequences of characters ending in a
null character.  Characters don't have a concept of "signedness" -
/numbers/ can be negative or positive, but characters cannot.  So "char"
is the natural type for a character, while "signed char" or "unsigned
char" is the natural type for a small integer.  And "strlen" is not a
sensible function to apply to an array of small integers, any more than
"+" is a sensible operation to apply to a character.

I would have preferred C to have a clearer distinction between "a very
small integer", "a character", and "a unit of memory" - but what we have
works well enough, especially if you are careful about your type names
and typedefs.

> 
>>>
>>> Anyone notice an obvious way that this mess could be tidied up?
>>
>> Yes - you could introduce some size-specific types so that people who
>> needed tighter specifications for their integer types could say exactly
>> what they wanted.
> 
> That's not tidying it up. It's brushing it under the carpet. Or rather,
> laying a new carpet on top of the old.
> 
>> Most uses of "char" are for storing letters or characters, or for
>> abstract byte storage - the signedness does not matter.
> 
> You've never had to compare one character with another? 

Yes - but testing for equality is not dependent on the signedness of char.

Perhaps you mean using < or > to provide an ordering on characters.  If
you live in a world of 7-bit ASCII and the most common letters in
English, and stick to either capital letters or small letters, then
these work fine with plain chars, signed chars or unsigned chars in
order to get alphabetical ordering.  You can also either use < and > to
get a somewhat arbitrary order that is consistent within your program
(which is fine in many situations), regardless of the signedness of
plain char.  For anything more than that, such as alphabetical sorting
of real languages, you need something more advanced anyway.

> Anyway 'char' is
> extensively used in place of a proper 'byte' type. Since byte values
> tend to be thought of unsigned 8-bit quantities, it seems perverse to
> use a 'char' that is either signed, or that you don't know whether it is
> signed or unsigned. And if you define byte as 'unsigned char' then you
> may run into the problems of having THREE incompatible char types as I
> showed above!

C standard library functions that deal with "memory", like memcpy, use
void* pointers to be compatible (without casts) with any pointer type.

> 
> Sorry, but it's still a mess.
> 

I am happy to agree that it is not perfect - but it is only a mess if
you write messy code.  I'd rather C had clearer distinctions in its
types so that it would be harder to mix up char types like this - but
you certainly /can/ write clear and simple code here.

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

#106547

On 20/03/2017 09:44, David Brown wrote:
> On 19/03/17 17:51, BartC wrote:

>> Do you mean that someone shouldn't need to care whether 'int' is signed
>> or 'unsigned' either?
>
> No.  If I had meant that, I would have written that.
>
> "int" is signed - that is /always/ the case.  If you want an unsigned
> equivalent type, "unsigned int" is there for you.
>
> But plain "char" may be signed and may be unsigned - it is
> implementation dependent.

That's the point: char is often used as a small integer, where it's even 
more important if the maximum value is 127 or 255 (or 9 old-style 
trillion, although in that case you're getting short-changed if you 
expected something compact).

   There have been cases of compilers on the
> same platform changing that choice between versions.  There is never,
> AFAIK, a reason why one would want to know or use the signedness of
> plain char - because there are perfectly good, clear, simple
> alternatives "signed char" and "unsigned char" that give you /exactly/
> what you want.

Which can give rise to type incompatibilities when linking to interfaces 
that just use plain char, as I showed.

 >  There is never,
 > AFAIK, a reason why one would want to know or use the signedness of
 > plain char

One reason is that plain 'char' seems to be used almost everywhere. 
'unsigned char' and especially 'signed char' is much less common, while 
'int8_t' and 'uint8_t' might as well not exist in open source code.

> Characters don't have a concept of "signedness" -
> /numbers/ can be negative or positive, but characters cannot.  So "char"
> is the natural type for a character,

The natural type for a character code - which is a number - is an 
unsigned value. I can't remember what bizarre set of circumstances made 
it be usually signed.

If it was to match up with short, int and long, then fair enough. But in 
that case 'char' would be guaranteed to be signed, and 'signed char' is 
exactly equivalent. But that's not the case.

, any more than
> "+" is a sensible operation to apply to a character.

Why not? I do char+offset or char-offset all the time.

> I would have preferred C to have a clearer distinction between "a very
> small integer", "a character", and "a unit of memory"

A 'byte'.

>> You've never had to compare one character with another?
>
> Yes - but testing for equality is not dependent on the signedness of char.
>
> Perhaps you mean using < or > to provide an ordering on characters.  If
> you live in a world of 7-bit ASCII and the most common letters in
> English, and stick to either capital letters or small letters, then
> these work fine with plain chars, signed chars or unsigned chars in
> order to get alphabetical ordering.  You can also either use < and > to
> get a somewhat arbitrary order that is consistent within your program
> (which is fine in many situations), regardless of the signedness of
> plain char.  For anything more than that, such as alphabetical sorting
> of real languages, you need something more advanced anyway.

This program will go wrong when c contains codes outside of the 0..127 
range:

   int histogram[256];
   char c;

   ++histogram[c];

Imagine its interface is like this:

     int fn(char *s){
     ...
      while (*s) {++histogram[*s]; ++s;}

If you changed char* to unsigned char* or uint8_t*, then it might 
generate type matching problems when passing the char* strings that most 
programs use.

What you seem to be saying is that people should code with char as 
though it was defined like this:

  #if RAND()&1
    #define CHAR signed char
  #else
    #define CHAR unsigned char
  #endif

Because, after all, it doesn't matter!

-- 
bartc

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

#106552

On Monday, March 20, 2017 at 2:01:17 PM UTC+2, Bart wrote:
> 
> One reason is that plain 'char' seems to be used almost everywhere. 
> 'unsigned char' and especially 'signed char' is much less common, while 
> 'int8_t' and 'uint8_t' might as well not exist in open source code.
>

Ninety percent of everything is crap. Open source code is no exception. Or a exception in a sense that percentage of crap is higher than 90%. But than again, it applies to all code, not just to open source. Open source just more visble.

But it does not follow from here that *you* have to use 'char', 'signed char' and 'unsigned char' in places where an intention is not for a character, but for a small integer.

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

#106560

On Mon, 20 Mar 2017 06:02:52 -0700 (PDT)
already5chosen@yahoo.com wrote:

> Ninety percent of everything is crap. Open source code is no exception. Or a
> exception in a sense that percentage of crap is higher than 90%. But than
> again, it applies to all code, not just to open source. Open source just more
> visble. But it does not follow from here that *you* have to use 'char', 'signed
> char' and 'unsigned char' in places where an intention is not for a character,
> but for a small integer. 

Indeed. That's why I think that "short" isn't badly defined as at least a 16-bit
integer. However "char" is here to stay so we have to deal with it.

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

#106564

On Monday, March 20, 2017 at 3:56:27 PM UTC+2, GOTHIER Nathan wrote:
> On Mon, 20 Mar 2017 06:02:52 -0700 (PDT)
> already5chosen@yahoo.com wrote:
> 
> > Ninety percent of everything is crap. Open source code is no exception. Or a
> > exception in a sense that percentage of crap is higher than 90%. But than
> > again, it applies to all code, not just to open source. Open source just more
> > visble. But it does not follow from here that *you* have to use 'char', 'signed
> > char' and 'unsigned char' in places where an intention is not for a character,
> > but for a small integer. 
> 
> Indeed. That's why I think that "short" isn't badly defined as at least a 16-bit
> integer.

That's not what I meant. In most places a proper numeric alternative to 'char' is either int8_t or uint8_t.


> However "char" is here to stay so we have to deal with it.

I don't feel like I has "to deal with it". I just use it where appropriate (i.e. for ASCII text and for generic storage) and don't use it where inappropriate (arithmetic).

Well, almost. I did use 'char' recently for one very special sort of arithmetic -  conversion from binary to decimal text. I.e. I did char c = n + '0'. That's because I am 100% sure that the code in question will never run on anything too weird. It's possible that going through indexing in const char decToC_tab[] = "0123456789" would be more portable, but to my taste it's too ugly.

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

#106575

On 20/03/17 15:28, already5chosen@yahoo.com wrote:
> On Monday, March 20, 2017 at 3:56:27 PM UTC+2, GOTHIER Nathan wrote:
>> On Mon, 20 Mar 2017 06:02:52 -0700 (PDT) already5chosen@yahoo.com
>> wrote:
>> 
>>> Ninety percent of everything is crap. Open source code is no
>>> exception. Or a exception in a sense that percentage of crap is
>>> higher than 90%. But than again, it applies to all code, not just
>>> to open source. Open source just more visble. But it does not
>>> follow from here that *you* have to use 'char', 'signed char' and
>>> 'unsigned char' in places where an intention is not for a
>>> character, but for a small integer.
>> 
>> Indeed. That's why I think that "short" isn't badly defined as at
>> least a 16-bit integer.
> 
> That's not what I meant. In most places a proper numeric alternative
> to 'char' is either int8_t or uint8_t.
> 
> 
>> However "char" is here to stay so we have to deal with it.
> 
> I don't feel like I has "to deal with it". I just use it where
> appropriate (i.e. for ASCII text and for generic storage) and don't
> use it where inappropriate (arithmetic).
> 
> Well, almost. I did use 'char' recently for one very special sort of
> arithmetic -  conversion from binary to decimal text. I.e. I did char
> c = n + '0'. That's because I am 100% sure that the code in question
> will never run on anything too weird. It's possible that going
> through indexing in const char decToC_tab[] = "0123456789" would be
> more portable, but to my taste it's too ugly.
> 

The characters '0' .. '9' are special cases - they are guaranteed to
appear consecutively in any valid character set for C.  So "c = n + '0'"
is entirely portable, assuming you know n is limited to 0 .. 9.

Using a lookup array is typically quite a good way to handle conversion
to hexidecimal digits.

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

#106578

already5chosen@yahoo.com writes:
[...]
> That's not what I meant. In most places a proper numeric alternative
> to 'char' is either int8_t or uint8_t.

Using int8_t or uint8_t makes sense only if you need a type that's
*exactly* 8 bits wide, with no padding bits or trap representations,
and represented in 2's-complement for int8_t, .  int8_t has a range
of exactly -128..+127.  uint8_t has a range of exactly 0..255.  Both
types are almost certain to exist in a C99 or later implementation
with 8-bit bytes, but they're not guaranteed to exist on all systems.

If you need a narrow numeric type with *at least* a certain range,
you can use [u]int_least8_t or [u]int_fast8_t, depending on your
requirements.  Or you can use signed char or unsigned char, both
of which are guaranteed to be at least 8 bits.  Or, if all you care
about is that the range is at least 0..127, you can even use plain
char (though for such a purpose either signed char or unsigned char
is likely to be more appropriate).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#106645

On 20/03/17 17:02, Keith Thompson wrote:
> already5chosen@yahoo.com writes:
> [...]
>> That's not what I meant. In most places a proper numeric alternative
>> to 'char' is either int8_t or uint8_t.
> 
> Using int8_t or uint8_t makes sense only if you need a type that's
> *exactly* 8 bits wide, with no padding bits or trap representations,
> and represented in 2's-complement for int8_t, .  int8_t has a range
> of exactly -128..+127.  uint8_t has a range of exactly 0..255.  Both
> types are almost certain to exist in a C99 or later implementation
> with 8-bit bytes, but they're not guaranteed to exist on all systems.
> 
> If you need a narrow numeric type with *at least* a certain range,
> you can use [u]int_least8_t or [u]int_fast8_t, depending on your
> requirements.  Or you can use signed char or unsigned char, both
> of which are guaranteed to be at least 8 bits.  Or, if all you care
> about is that the range is at least 0..127, you can even use plain
> char (though for such a purpose either signed char or unsigned char
> is likely to be more appropriate).
> 

That is all correct.  In /most/ places, if you need a very small numeric
type, then int8_t or uint8_t is the correct type.  There are certainly
systems that don't have CHAR_BIT equal to 8, and thus don't have these
types.  And there are a few odd dinosaurs that having padding bits or
one's complement signed types.  But are you likely to actually need a
minimal sized numeric type in code that will run on such systems?  In
particular, are you likely to write code that needs minimal sized
numeric types, and the code is likely to be used both on systems that
support int8_t and systems that do not?

Yes, there may be occasions when uint_least8_t (or uint_fast8_t) is
appropriate for portability.  But I think in the huge majority of
situations where you might want uint_least8_t, then uint8_t would work
just as well - and it is simpler and clearer, and gives you stronger
guarantees.  And unlike some other assumptions about
implementation-defined behaviour, or platforms that don't support the
type you will get an obvious compile-time failure.

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

#106648

On Tuesday, March 21, 2017 at 11:12:04 AM UTC+2, David Brown wrote:
> On 20/03/17 17:02, Keith Thompson wrote:
> > already5chosen@yahoo.com writes:
> > [...]
> >> That's not what I meant. In most places a proper numeric alternative
> >> to 'char' is either int8_t or uint8_t.
> > 
> > Using int8_t or uint8_t makes sense only if you need a type that's
> > *exactly* 8 bits wide, with no padding bits or trap representations,
> > and represented in 2's-complement for int8_t, .  int8_t has a range
> > of exactly -128..+127.  uint8_t has a range of exactly 0..255.  Both
> > types are almost certain to exist in a C99 or later implementation
> > with 8-bit bytes, but they're not guaranteed to exist on all systems.
> > 
> > If you need a narrow numeric type with *at least* a certain range,
> > you can use [u]int_least8_t or [u]int_fast8_t, depending on your
> > requirements.  Or you can use signed char or unsigned char, both
> > of which are guaranteed to be at least 8 bits.  Or, if all you care
> > about is that the range is at least 0..127, you can even use plain
> > char (though for such a purpose either signed char or unsigned char
> > is likely to be more appropriate).
> > 
> 
> That is all correct.  In /most/ places, if you need a very small numeric
> type, then int8_t or uint8_t is the correct type.  There are certainly
> systems that don't have CHAR_BIT equal to 8, and thus don't have these
> types.  And there are a few odd dinosaurs that having padding bits or
> one's complement signed types.  But are you likely to actually need a
> minimal sized numeric type in code that will run on such systems?  In
> particular, are you likely to write code that needs minimal sized
> numeric types, and the code is likely to be used both on systems that
> support int8_t and systems that do not?
> 
> Yes, there may be occasions when uint_least8_t (or uint_fast8_t) is
> appropriate for portability.  But I think in the huge majority of
> situations where you might want uint_least8_t, then uint8_t would work
> just as well - and it is simpler and clearer, and gives you stronger
> guarantees.  And unlike some other assumptions about
> implementation-defined behaviour, or platforms that don't support the
> type you will get an obvious compile-time failure.

I'd formulate it shorter: Keith's comment is a good example of extreme legalism far removed from real life of programming in C in general and from programming in C for embedded systems in particular.

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

#106680

already5chosen@yahoo.com writes:
[...]
>> On 20/03/17 17:02, Keith Thompson wrote:
>> > already5chosen@yahoo.com writes:
>> > [...]
>> >> That's not what I meant. In most places a proper numeric alternative
>> >> to 'char' is either int8_t or uint8_t.
>> > 
>> > Using int8_t or uint8_t makes sense only if you need a type that's
>> > *exactly* 8 bits wide, with no padding bits or trap representations,
>> > and represented in 2's-complement for int8_t, .  int8_t has a range
>> > of exactly -128..+127.  uint8_t has a range of exactly 0..255.  Both
>> > types are almost certain to exist in a C99 or later implementation
>> > with 8-bit bytes, but they're not guaranteed to exist on all systems.
>> > 
>> > If you need a narrow numeric type with *at least* a certain range,
>> > you can use [u]int_least8_t or [u]int_fast8_t, depending on your
>> > requirements.  Or you can use signed char or unsigned char, both
>> > of which are guaranteed to be at least 8 bits.  Or, if all you care
>> > about is that the range is at least 0..127, you can even use plain
>> > char (though for such a purpose either signed char or unsigned char
>> > is likely to be more appropriate).
[...]
> I'd formulate it shorter: Keith's comment is a good example of extreme
> legalism far removed from real life of programming in C in general and
> from programming in C for embedded systems in particular.

How so?  uint8_t, uint_least8_t, and uint_fast8_t are all defined in the
same header.  Why use one that imposes more guarantees than you need?
(Of course if you actually need those guarantees, you should use
uint8_t.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#106679

David Brown <david.brown@hesbynett.no> writes:
> On 20/03/17 17:02, Keith Thompson wrote:
>> already5chosen@yahoo.com writes:
>> [...]
>>> That's not what I meant. In most places a proper numeric alternative
>>> to 'char' is either int8_t or uint8_t.
>> 
>> Using int8_t or uint8_t makes sense only if you need a type that's
>> *exactly* 8 bits wide, with no padding bits or trap representations,
>> and represented in 2's-complement for int8_t, .  int8_t has a range
>> of exactly -128..+127.  uint8_t has a range of exactly 0..255.  Both
>> types are almost certain to exist in a C99 or later implementation
>> with 8-bit bytes, but they're not guaranteed to exist on all systems.
>> 
>> If you need a narrow numeric type with *at least* a certain range,
>> you can use [u]int_least8_t or [u]int_fast8_t, depending on your
>> requirements.  Or you can use signed char or unsigned char, both
>> of which are guaranteed to be at least 8 bits.  Or, if all you care
>> about is that the range is at least 0..127, you can even use plain
>> char (though for such a purpose either signed char or unsigned char
>> is likely to be more appropriate).
>
> That is all correct.

So you agree with me.

>                       In /most/ places, if you need a very small numeric
> type, then int8_t or uint8_t is the correct type.

So you disagree with me.

[...]

> Yes, there may be occasions when uint_least8_t (or uint_fast8_t) is
> appropriate for portability.  But I think in the huge majority of
> situations where you might want uint_least8_t, then uint8_t would work
> just as well - and it is simpler and clearer, and gives you stronger
> guarantees.

And what if you don't need those stronger guarantees?  How often do you
care whether a signed type uses two's-complement or not?

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#106684

On Tuesday, March 21, 2017 at 10:17:14 AM UTC-5, Keith Thompson wrote:
> > Yes, there may be occasions when uint_least8_t (or uint_fast8_t) is
> > appropriate for portability.  But I think in the huge majority of
> > situations where you might want uint_least8_t, then uint8_t would work
> > just as well - and it is simpler and clearer, and gives you stronger
> > guarantees.
> 
> And what if you don't need those stronger guarantees?  How often do you
> care whether a signed type uses two's-complement or not?

Probably about as often as one cares about padding bits.  A fair amount of
code would benefit from a guarantee that any padding bits that might be
present will be ignored when read and zeroed when written, and from a
guarantee that if intN_t and int(2N)_t are both defined, a value of the
larger size will be stored as two consecutive values of the smaller in a
known-endian format.  If there were a family of intNbe_t and intNle_t and
likewise for uintNbe_t and uintNle_t meeting the above criteria, and if the
rules for intN_t and uintN_t were loosened to allow implementations to treat
them as equivalent to intNbe_t or intNle_t even if they have padding bits,
many systems with unusual word sizes could gain the ability to run a lot of
code which is designed for more conventional machines.  Efficiency may not
be super, but could probably be better than code which had to use a bunch of
manual shifting.

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

#106692

On 21/03/17 16:17, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 20/03/17 17:02, Keith Thompson wrote:
>>> already5chosen@yahoo.com writes:
>>> [...]
>>>> That's not what I meant. In most places a proper numeric alternative
>>>> to 'char' is either int8_t or uint8_t.
>>>
>>> Using int8_t or uint8_t makes sense only if you need a type that's
>>> *exactly* 8 bits wide, with no padding bits or trap representations,
>>> and represented in 2's-complement for int8_t, .  int8_t has a range
>>> of exactly -128..+127.  uint8_t has a range of exactly 0..255.  Both
>>> types are almost certain to exist in a C99 or later implementation
>>> with 8-bit bytes, but they're not guaranteed to exist on all systems.
>>>
>>> If you need a narrow numeric type with *at least* a certain range,
>>> you can use [u]int_least8_t or [u]int_fast8_t, depending on your
>>> requirements.  Or you can use signed char or unsigned char, both
>>> of which are guaranteed to be at least 8 bits.  Or, if all you care
>>> about is that the range is at least 0..127, you can even use plain
>>> char (though for such a purpose either signed char or unsigned char
>>> is likely to be more appropriate).
>>
>> That is all correct.
>
> So you agree with me.
>
>>                       In /most/ places, if you need a very small numeric
>> type, then int8_t or uint8_t is the correct type.
>
> So you disagree with me.
>
> [...]
>
>> Yes, there may be occasions when uint_least8_t (or uint_fast8_t) is
>> appropriate for portability.  But I think in the huge majority of
>> situations where you might want uint_least8_t, then uint8_t would work
>> just as well - and it is simpler and clearer, and gives you stronger
>> guarantees.
>
> And what if you don't need those stronger guarantees?  How often do you
> care whether a signed type uses two's-complement or not?
>

Sometimes I /do/ care about the format for signed numbers.  And very 
often, I /do/ care that my small types are exactly 8 bits.  It is a good 
deal more common for me to care that they are exactly 8 bits than it is 
for me to care if the code would work on 16-bit char systems (and I 
expect I have worked with 16-bit and 32-bit char systems more than most 
people in this group).

I could write my code with a mixture of uint8_t and uint_least8_t types 
- only using the uint8_t one when it was necessary.  But that would mean 
a mixture of types, with boundaries between them - sometimes needing 
casts, sometimes needing memcpy to be sure that there are no aliasing 
issues, and so on.  The code is simpler and clearer if I consistently 
use uint8_t and have the stronger type guarantees whether I need them or 
not.  Readability, simplicity, and maintainability trump portability in 
this case (for my use, at least).

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

#107064

already5chosen@yahoo.com wrote:
> On Monday, March 20, 2017 at 3:56:27 PM UTC+2, GOTHIER Nathan wrote:
>> On Mon, 20 Mar 2017 06:02:52 -0700 (PDT) already5chosen@yahoo.com
>> wrote:
>>
>>> Ninety percent of everything is crap. Open source code is no
>>> exception. Or a exception in a sense that percentage of crap is
>>> higher than 90%. But than again, it applies to all code, not just
>>> to open source. Open source just more visble. But it does not
>>> follow from here that *you* have to use 'char', 'signed char' and
>>> 'unsigned char' in places where an intention is not for a
>>> character, but for a small integer.
>>
>> Indeed. That's why I think that "short" isn't badly defined as at
>> least a 16-bit integer.
>
> That's not what I meant. In most places a proper numeric alternative
> to 'char' is either int8_t or uint8_t.
>
>
>> However "char" is here to stay so we have to deal with it.
>
> I don't feel like I has "to deal with it". I just use it where
> appropriate (i.e. for ASCII text and for generic storage) and don't
> use it where inappropriate (arithmetic).
>

It's also reasonable as a makeshift "bool" type, if you don't
have one built in.

> Well, almost. I did use 'char' recently for one very special sort of
> arithmetic -  conversion from binary to decimal text. I.e. I did char
> c = n + '0'. That's because I am 100% sure that the code in question
> will never run on anything too weird. It's possible that going
> through indexing in const char decToC_tab[] = "0123456789" would be
> more portable, but to my taste it's too ugly.
>
>

Seriously? You have to understand the level to which code needs to be 
portable well ahead of starting work. Most code is never ported, and
there is only so much you can do up front anyway. Porting is
usually a YAGNI.

-- 
Les Cargill

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

#107084

On Saturday, March 25, 2017 at 8:10:33 PM UTC, Les Cargill wrote:
> 
> Seriously? You have to understand the level to which code needs to be 
> portable well ahead of starting work. Most code is never ported, and
> there is only so much you can do up front anyway. Porting is
> usually a YAGNI.
> 
Most people think, reasonably enough, that the reason for making code 
portable is to compile and run it on two different architectures.
In fact the code structure benefits if as much is portable as possible.

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

#107090

Malcolm McLean wrote:
> On Saturday, March 25, 2017 at 8:10:33 PM UTC, Les Cargill wrote:
>>
>> Seriously? You have to understand the level to which code needs to be
>> portable well ahead of starting work. Most code is never ported, and
>> there is only so much you can do up front anyway. Porting is
>> usually a YAGNI.
>>
> Most people think, reasonably enough, that the reason for making code
> portable is to compile and run it on two different architectures.
> In fact the code structure benefits if as much is portable as possible.
>
>

Unfortunately, many times "portable" is interpreted as
"leave blocks of #ifdef around significant portions of
the code base" and there is no way that this improves
anything beyond portability.

-- 
Les Cargill

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

#107100

On 26/03/2017 05:53, Les Cargill wrote:
> Malcolm McLean wrote:
>> On Saturday, March 25, 2017 at 8:10:33 PM UTC, Les Cargill wrote:
>>>
>>> Seriously? You have to understand the level to which code needs to be
>>> portable well ahead of starting work. Most code is never ported, and
>>> there is only so much you can do up front anyway. Porting is
>>> usually a YAGNI.
>>>
>> Most people think, reasonably enough, that the reason for making code
>> portable is to compile and run it on two different architectures.
>> In fact the code structure benefits if as much is portable as possible.
>>
>>
>
> Unfortunately, many times "portable" is interpreted as
> "leave blocks of #ifdef around significant portions of
> the code base" and there is no way that this improves
> anything beyond portability.

No, some people just like to use lots of #ifs and #ifdefs whether it's 
for portability reasons or not.

I tested two programs, one containing only "#include <stdio.h>", the 
other "#include <windows.h>", and measured how many #if, #ifdef, and 
'#ifndefs' were seen (including those in false #if branches), using sets 
of includes from various compilers:

               stdio.h       windows.h   Lines in windows.h
lccwin32           17             130     19K  #if every 140 lines
DMC                40            4300    160K, every 37 lines
Pelles C           50            7000    147K, every 20 lines
Tiny C            100             730     27K, every 37 lines
MSVC              280           11700    680K, every 55 lines
gcc/mingw         450           20000    340K, every 17 lines

(windows.h probably includes stdio and other headers)

windows.h is not a header you'd expect to need to be that portable, so 
what are all the #ifs for?

It just seems to go with C programming. Or with other people's C 
programming, as my own hardly uses #if at all. The CPP is a tool that 
tends to be over-used from what I've seen of open-source. Especially by 
everyone involved with gcc!

-- 
bartc

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

#107120

On Sunday, March 26, 2017 at 6:30:30 AM UTC-5, Bart wrote:
> windows.h is not a header you'd expect to need to be that portable, so 
> what are all the #ifs for?

Did you filter out #if blocks that are used to avoid multiple-definition
errors?

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

#107121

On 26/03/2017 22:09, supercat@casperkitty.com wrote:
> On Sunday, March 26, 2017 at 6:30:30 AM UTC-5, Bart wrote:
>> windows.h is not a header you'd expect to need to be that portable, so
>> what are all the #ifs for?
>
> Did you filter out #if blocks that are used to avoid multiple-definition
> errors?

The metric includes #ifxxx lines even if they are in code that is 
skipped. So for:

#if 0
    #if 1
    #endif
#endif

the count is 2.

After all, a program processing this code still has to scan them, and 
someone looking at the code still have absorb that extra complexity as 
it will not be clear what will or won't be compiled.

-- 
bartc

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

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

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

csiph-web