Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #106567
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Array allocated on stack or heap |
| Date | 2017-03-20 15:34 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <oaop52$k0d$1@dont-email.me> (permalink) |
| References | (6 earlier) <oalsds$83n$1@dont-email.me> <oaluoh$sbs$1@dont-email.me> <oamco9$h2k$1@dont-email.me> <oao843$nnf$1@dont-email.me> <oaog4l$jl3$1@dont-email.me> |
On 20/03/17 13:01, BartC wrote:
> 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).
>
Some people write bad code - or at least, needlessly non-portable and
unclear code. I can't help that. I can encourage /you/, and others, to
write better code. And I can point out that C has types that are
designed for use as small integers - int8_t and related types. But I
can't stop people from writing bad code or making unreasonable
assumptions - nor can any programming language. For the most part, all
a programming language can do is give people the tools they need to
write /good/ code.
> 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.
No, you won't get linking incompatibilities. But you might get problems
if people have made unwarranted assumptions about the signedness of
char, either when writing the function or when writing code that uses
the function. That is why compilers will often warn about sign
mismatches in pointers like this - even though C defines access to data
via pointers of different signedness.
>
>> 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.
>
It is rare that anyone actually /needs/ a small integer like that. For
most programming, it is only useful when you need to be particularly
compact - and most programmers working on PC's, open source or not, view
memory as cheap. C encourages the use of "int" as a the normal type for
an integer number, and people go with that.
The places you will see uint8_t and int8_t are embedded systems
(especially small ones), data that matches a fixed format (such as a
disk format or file format), RGB data, and sometimes for very large
arrays of small values. I think that applies regardless of whether it
is open source code or closed source - I can't imagine any significant
relevance of the development model.
"char" is often used for data buffers or memory blocks where the
signedness does not matter - I have rarely seen it for storing a number.
And when it /is/ used for a number, the number is typically small
enough that the signedness does not matter.
>> 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.
I too think the concept of a "signed char" is a daft name - the only
good use for it is as a typedef for "int8_t" or similar types (for cases
where <stdint.h> is not available). But while the name is bad, the type
works fine.
And I cannot see why anyone would want a negative character. But I
suppose that in the past, someone thought 7 bits were enough to hold any
character they wanted - and then it was a question of whether it was
more efficient to view it as a signed 8-bit value or an unsigned 8-bit
value on particular systems.
>
> 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.
Why? I can think of a few possible uses, but mostly they are
implementation-dependent (like assuming alphabetical order for letters),
and they are hardly something that one would do "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'.
Yes, that would be the logical choice of name.
>
>>> 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];
>
Yes, it is code that depends on the signedness of char. Either it is
implementation-specific, or it is incorrect.
> 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.
You just have to write correct code - both for the calling function, and
the called function. There is no problem doing that here.
>
> 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
All /my/ code would be unchanged by this.
>
> Because, after all, it doesn't matter!
>
It /should/ not matter - but some people write code where it /does/ matter.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web