Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #106122 > unrolled thread
| Started by | mertesthomas@gmail.com |
|---|---|
| First post | 2017-03-15 00:29 -0700 |
| Last post | 2017-03-15 16:32 +0000 |
| Articles | 20 on this page of 127 — 23 participants |
Back to article view | Back to comp.lang.c
More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 00:29 -0700
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 11:27 +0100
Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 13:18 +0000
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 15:22 +0100
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 08:26 -0700
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 08:25 -0700
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 16:46 +0100
Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-15 17:07 +0100
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 09:52 -0700
Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 16:57 +0000
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 10:11 -0700
Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 18:17 +0000
Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 17:21 +0000
Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-15 18:42 +0100
Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 18:20 +0000
Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 18:59 +0000
Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-15 18:20 +0000
Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-15 19:39 +0100
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 12:44 -0700
Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-15 20:19 +0000
Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 10:03 +0100
Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-16 11:15 +0000
Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-16 11:32 +0000
Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 13:41 +0100
Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-16 08:52 +0100
Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 09:57 +0100
Re: More problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-16 13:53 +0000
Re: More problems with lcc-win jm.bourguet@gmail.com - 2017-03-16 07:14 -0700
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-16 08:59 -0700
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 12:43 -0700
Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 20:39 +0000
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:56 +0100
Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 16:33 +0000
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 17:47 +0100
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 10:04 -0700
Re: More problems with lcc-win jacob navia <jacob@jacob.remcomp.fr> - 2017-03-16 00:52 +0100
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 18:02 -0700
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 18:23 -0700
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-17 13:45 -0700
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:23 +0100
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:29 +0100
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:31 +0100
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-17 17:01 -0700
Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-20 16:41 +0000
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-20 18:32 +0100
Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-20 18:18 +0000
Re: More problems with lcc-win bart4858@gmail.com - 2017-03-20 12:31 -0700
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-20 21:05 +0100
Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-20 20:45 +0000
Re: More problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-20 20:18 +0000
Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-21 09:56 +0100
Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-21 21:08 +0000
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-21 22:19 +0100
Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-22 06:29 +0000
Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-21 16:12 -0700
Re: More problems with lcc-win gordonb.s97bd@burditt.org (Gordon Burditt) - 2017-03-24 01:13 -0500
Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-24 08:16 -0700
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-26 03:18 -0700
Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-26 12:35 +0100
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-29 05:17 -0700
Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-26 14:04 -0700
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-29 05:48 -0700
Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-21 23:21 +0000
Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-22 06:18 +0000
Re: More problems with lcc-win gordonb.1neik@burditt.org (Gordon Burditt) - 2017-03-21 18:45 -0500
Re: More problems with lcc-win jm.bourguet@gmail.com - 2017-03-22 01:02 -0700
Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-22 10:35 +0100
Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-22 13:21 +0000
Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-22 14:08 +0000
Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-22 15:37 +0000
Re: More problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-22 21:09 +0000
Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 13:09 +0000
Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-21 21:15 +0000
Re: More problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-18 12:44 +1300
Re: More problems with lcc-win jameskuyper@verizon.net - 2017-03-17 16:59 -0700
Re: charsets Noob <root@127.0.0.1> - 2017-03-18 18:30 +0100
Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 10:18 +0100
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 15:06 -0700
Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 22:23 +0000
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 15:43 -0700
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:53 +0100
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-16 08:35 -0700
Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 23:13 +0000
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-16 06:28 -0700
Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-16 16:56 +0000
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-16 14:53 -0700
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 16:18 -0700
Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-16 18:03 +0000
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-16 19:29 +0100
Re: More problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-16 21:38 +0000
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-17 08:58 -0700
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-17 09:45 -0700
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-17 10:33 -0700
Re: More problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-17 14:20 -0400
Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-17 20:18 +0100
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 00:44 -0700
Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-18 13:31 +0000
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 15:54 -0700
Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-20 13:27 +0000
Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-18 15:15 +0100
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 11:39 -0700
Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-18 20:11 +0100
Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-18 19:45 +0000
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-20 00:35 -0700
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 14:22 -0700
Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-18 22:46 +0100
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 16:12 -0700
Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-18 18:01 -0700
Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 03:21 +0100
Re: More problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-19 15:32 +1300
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-19 02:17 -0700
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:25 -0700
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:49 +0100
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 11:28 +0100
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:35 -0700
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:44 +0100
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 13:06 +0100
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:43 -0700
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:43 +0100
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 13:19 +0100
Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:50 -0700
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 08:24 -0700
Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 16:47 +0100
Re: More problems with lcc-win jameskuyper@verizon.net - 2017-03-15 09:04 -0700
Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 09:15 -0700
Re: More problems with lcc-win gazelle@shell.xmission.com (Kenny McCormack) - 2017-03-15 19:59 +0000
Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 16:32 +0000
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-16 10:03 +0100 |
| Message-ID | <oadk7b$imu$1@dont-email.me> |
| In reply to | #106173 |
On 15/03/17 21:19, BartC wrote: > On 15/03/2017 19:44, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: >> [...] >>> Now the common situation when 'int' is 32 bits, is that 'long long' is >>> 64 bits; what's the point of 'long'? >> >> The point is that int is at least 16 bits (and encouraged to be the >> "natural" size for the machine in some vaguely defined sense), long is >> at least 32 bits, and long long is at least 64 bits. You can write a >> lot of code relying only on those guarantees. > > The COMMON situation is that int is 32 bits and long long is 64 bits. > Then when would you use long? It's no longer an in-between value, and > it's no longer even longer than int, if that's how it was used. > > And when int is 16 bits, then what's the point of 'short'. > > Here's the current set of int types and their typical widths on x86 and > ARM: > > char 8 > short 16 > int 32 > long ?? > long long 64 > > And when int is 16 bits: > > char 8 > short ?? "short" is always at least 16 bits, and no longer than "int" - thus it is fixed at 16-bits in this case. > int 16 > long 32 > long long 64 > > Notice the odd one out in each case... > > I think it could have been handled better. > The type sizes in C are a compromise between giving enough guarantees of minimum ranges to be useful in a lot of programs, while being flexible enough to allow a lot of different implementations. There are C implementations where "short", "int" and "long" are all 64 bits. There are implementations where they are all 32-bit, as are "char". There are implementations where char is 8 bit, short is 16 bit, int is 24 bit and long is 32 bit. The values you give above are by far the most common choices - but they are not the only ones supported by C. And there /is/ an alternative that handles it differently (mostly "better", IMHO - but not better in every way) - the fixed size types in <stdint.h>.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-16 11:15 +0000 |
| Message-ID | <oadrv2$bfv$1@dont-email.me> |
| In reply to | #106236 |
On 16/03/2017 09:03, David Brown wrote:
> On 15/03/17 21:19, BartC wrote:
>> Here's the current set of int types and their typical widths on x86 and
>> ARM:
>> Notice the odd one out in each case...
>>
>> I think it could have been handled better.
> And there /is/ an alternative that handles it differently (mostly
> "better", IMHO - but not better in every way) - the fixed size types in
> <stdint.h>.
There is something about how stdint.h works. First, all those intN_t
types are just defined on top of char, short, int, long, long long anyway!
But also the behaviour changes. Take this code using traditional types:
int *a;
long *b;
long long *c;
a=b;
b=c;
printf("%d %ld %lld",(int)0, (long)0, (long long)0);
You would expect type errors on both assignments, but the formats to be
fine. Now change to the equivalent using intN_t types:
int32_t *a;
//int32_t *b; // comment of these b's out
int64_t *b;
long long *c;
a=b;
b=c;
printf("%d %ld %lld",(int32_t)0, (int64_t)0, (int64_t)0);
Now only one of the assignments is a type error. And you can get an
extra error in the formats. (Of course all formats would need upgrading
Maybe this would never be of practical significance, but it seems to me
amiss that you can't recreate the behaviour of the funny in-between
'long' type using fixed-width types.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-16 11:32 +0000 |
| Message-ID | <oadsur$ei2$1@dont-email.me> |
| In reply to | #106238 |
On 16/03/2017 11:15, BartC wrote: > There is something about how stdint.h works. > But also the behaviour changes. Take this code using traditional types: > Now change to the equivalent using intN_t types: > > int32_t *a; > //int32_t *b; // comment of these b's out > int64_t *b; > long long *c; That last should be int64_t c. However my comments aren't affected (because 'int64_t' is mostly likely just an alias for 'long long').
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-16 13:41 +0100 |
| Message-ID | <oae0vm$rhf$1@dont-email.me> |
| In reply to | #106238 |
On 16/03/17 12:15, BartC wrote:
> On 16/03/2017 09:03, David Brown wrote:
>> On 15/03/17 21:19, BartC wrote:
>
>>> Here's the current set of int types and their typical widths on x86 and
>>> ARM:
>
>>> Notice the odd one out in each case...
>>>
>>> I think it could have been handled better.
>
>> And there /is/ an alternative that handles it differently (mostly
>> "better", IMHO - but not better in every way) - the fixed size types in
>> <stdint.h>.
>
> There is something about how stdint.h works. First, all those intN_t
> types are just defined on top of char, short, int, long, long long anyway!
/Usually/ that is the case - but it does not have to be that way. It
can be defined in an implementation-specific way. On the AVR port of
gcc, <stdint.h> has this:
typedef int int8_t __attribute__((__mode__(__QI__)));
typedef unsigned int uint8_t __attribute__((__mode__(__QI__)));
typedef int int16_t __attribute__ ((__mode__ (__HI__)));
typedef unsigned int uint16_t __attribute__ ((__mode__ (__HI__)));
typedef int int32_t __attribute__ ((__mode__ (__SI__)));
typedef unsigned int uint32_t __attribute__ ((__mode__ (__SI__)));
But even with definitions in terms of the standard types, since
<stdint.h> is part of the implementation it knows exactly what sizes
these types are.
>
> But also the behaviour changes. Take this code using traditional types:
>
> int *a;
> long *b;
> long long *c;
>
> a=b;
> b=c;
> printf("%d %ld %lld",(int)0, (long)0, (long long)0);
>
>
> You would expect type errors on both assignments, but the formats to be
> fine. Now change to the equivalent using intN_t types:
>
> int32_t *a;
> //int32_t *b; // comment of these b's out
> int64_t *b;
> long long *c;
>
> a=b;
> b=c;
> printf("%d %ld %lld",(int32_t)0, (int64_t)0, (int64_t)0);
>
> Now only one of the assignments is a type error. And you can get an
> extra error in the formats. (Of course all formats would need upgrading
>
Yes. You should consider "int*" and "int32_t*" to be incompatible, and
the same applies to any other combination. Usually (baring an even
odder implementation than the one for the AVR above) some combinations
will work, but it will vary according to the implementation. You are
not even guaranteed that "int32_t *", "int_fast32_t *" and
"int_least32_t *" are compatible on a 32-bit system.
And for printf and friends, you need to use the macros in <inttypes.h>
(or use casts like you did). Ugly, it's true, but it works.
> Maybe this would never be of practical significance, but it seems to me
> amiss that you can't recreate the behaviour of the funny in-between
> 'long' type using fixed-width types.
>
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-03-16 08:52 +0100 |
| Message-ID | <20170316085200.3d16f1c2b4516b62a27a5453@gmail.com> |
| In reply to | #106155 |
On Wed, 15 Mar 2017 18:20:20 +0000 BartC <bc@freeuk.com> wrote: > Why? I thought C types weren't defined as exact widths. So long merely > had to be at least as wide as int, and at least 32 bits. > > Making long 64 bits oughtn't to have broken any properly written programs. > > Now the common situation when 'int' is 32 bits, is that 'long long' is > 64 bits; what's the point of 'long'? Actually on 16-bit implementations mandating long to support at least 64-bit integers would considerably slow the calculation with aggregates. Thus the invention of long long make sense in this case but still the syntax is moot.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-16 09:57 +0100 |
| Message-ID | <oadjt4$hk7$1@dont-email.me> |
| In reply to | #106155 |
On 15/03/17 19:20, BartC wrote: > On 15/03/2017 17:42, GOTHIER Nathan wrote: >> On Wed, 15 Mar 2017 17:21:48 +0000 >> Richard Heathfield <rjh@cpax.org.uk> wrote: >> >>> Yes, but it's a problem that could easily have been avoided by making >>> long 64 bits (or longer, if need be) and ignoring long long completely. >> >> Wrong since 32-bit long code would be invalid redefining long to be >> 64-bit or >> more. The committee guideline aims at no breaking existing code with >> new rules. > > Why? I thought C types weren't defined as exact widths. So long merely > had to be at least as wide as int, and at least 32 bits. > > Making long 64 bits oughtn't to have broken any properly written programs. The trouble was the improperly written programs. Since the days of 16-bit Windows, Windows programmers have been equating "long" with "32-bit". That remained the case with 32-bit Windows. When deciding about the 64-bit ABI, MS faced a dilemma. The obvious choice was to use the same ABI that everyone else used on x86-64, and the most common choice for 64-bit ABIs in general, with 64-bit longs. But that would break code that assumed "long" is 32-bit. On the third hand, leaving "long" as 32-bit would break code that assumed "long" can hold a pointer. In the end, they decided that keeping long at 32-bit would break less code. Whether such improperly written code was from third-party applications, or MS's own code for the Windows system or their applications, is unknown AFAIK. > > Now the common situation when 'int' is 32 bits, is that 'long long' is > 64 bits; what's the point of 'long'? > It is useful for portable code - not every system has 32-bit "int". And if you don't have C99, then you don't have "long long". As 32-bit int gets more common, and C90 becomes less common, then "long" is becoming less necessary. If you are writing code for *nix and/or Windows, and you are not limited to C90, then you are not going to need "long" for anything except when dealing with third-party functions that use it. It is important to note that "long long", "long" and "int" are considered separate types in C, even if they overlap in size. Pointers to these types are not compatible, and the compiler will assume they don't alias. For my own code, if I want specific sized types (and I usually do), I stick to the types from <stdint.h>. When I want 32 bits, I normally use "int32_t" or "uint32_t" - not "long" or "int".
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-03-16 13:53 +0000 |
| Message-ID | <oae5d5$72h$1@z-news.wcss.wroc.pl> |
| In reply to | #106151 |
GOTHIER Nathan <nathan.gothier@gmail.com> wrote:
> On Wed, 15 Mar 2017 17:21:48 +0000
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
> > Yes, but it's a problem that could easily have been avoided by making
> > long 64 bits (or longer, if need be) and ignoring long long completely.
>
> Wrong since 32-bit long code would be invalid redefining long to be 64-bit or
> more. The committee guideline aims at no breaking existing code with new rules.
Actually C90 required long to be big enough to store pointers. So
on 64-bit machines long was _required_ to be 64 bit. It was only
Microsoft insistence that standard was amended.
Concerning compatibility, 32-bit long in general causes more
problems than it solves. In particular it broke all programs
depending on casts between long and pointers. But Microsoft
was only interested in codebase running on Windows where
programmers incorrectly assumend fixed sizes of various types.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | jm.bourguet@gmail.com |
|---|---|
| Date | 2017-03-16 07:14 -0700 |
| Message-ID | <dd5fc57c-6bc7-413c-b09e-d6582920afcc@googlegroups.com> |
| In reply to | #106245 |
Le jeudi 16 mars 2017 14:53:48 UTC+1, anti...@math.uni.wroc.pl a écrit :
> Actually C90 required long to be big enough to store pointers.
Do you have a reference for that? I may have missed something, but it's not in 6.2.2.3 and 6.3.4 says
A pointer may be converted to an integral type. The size of integer
required and the result are implementation-defined, if the space
provided is not long enough, the behavior is undefined.
which seems difficult to interpret as consistent with your affirmation.
Yours,
--
Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-16 08:59 -0700 |
| Message-ID | <lno9x1fc07.fsf@kst-u.example.com> |
| In reply to | #106245 |
antispam@math.uni.wroc.pl writes:
[...]
> Actually C90 required long to be big enough to store pointers. So
> on 64-bit machines long was _required_ to be 64 bit. It was only
> Microsoft insistence that standard was amended.
Not true.
C99 introduced intptr_t and uintptr_t, but they're optional. In C90,
C99, and C11, it's perfectly valid for pointers to be wider than *any*
integer type
[...]
--
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]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-15 12:43 -0700 |
| Message-ID | <lnlgs6gwbh.fsf@kst-u.example.com> |
| In reply to | #106150 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 15/03/17 16:52, Keith Thompson wrote:
>
> <snip>
>
>> But the standard makes the
>> second parameter of fseek, as well as the return type of ftell, long.
>>
>> This is IMHO a flaw in the standard.
>
> I disagree. I think there is a flaw in some implementations.
>
>> I could argue that 64-bit Windows
>> *should* have made long 64 bits, as 64-bit Linux does, but making it 32
>> bits is perfectly valid.
>
> Although 32-bit long is perfectly valid, I would agree that Microsoft
> should have extended long to 64 bits. In fact, IIRC I argued at the
> time that 'long long' was an unnecessary introduction, as a bigger
> long would do exactly the same job and would require no changes to the
> Standard.
The same argument would support using unsigned long rather than size_t
as the result of sizeof (one difference being that size_t was introduced
by C89).
Leaving Windows aside, even 32-bit systems can easily have files bigger
than 2GB (though that was less likely back in 1990). Using something
similar to POSIX's off_t (a signed integer type, not to be confused with
the fpos_t type used by ISO C's fsetpos() and fgetpos()) would IMHO be
an improvement over using a *specific* predefined integer type like
long.
There are good (but futile) arguments in favor of making long 64 bits on
64-bit Windows, but I'd like to separate file offsets from those
arguments.
[...]
--
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]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-15 20:39 +0000 |
| Message-ID | <oac8jt$7jb$1@dont-email.me> |
| In reply to | #106166 |
On 15/03/17 19:43, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> On 15/03/17 16:52, Keith Thompson wrote: >> <snip> >> >>> I could argue that 64-bit Windows >>> *should* have made long 64 bits, as 64-bit Linux does, but making it 32 >>> bits is perfectly valid. >> >> Although 32-bit long is perfectly valid, I would agree that Microsoft >> should have extended long to 64 bits. In fact, IIRC I argued at the >> time that 'long long' was an unnecessary introduction, as a bigger >> long would do exactly the same job and would require no changes to the >> Standard. > > The same argument would support using unsigned long rather than size_t > as the result of sizeof (one difference being that size_t was introduced > by C89). It would indeed. The size_t type is a bit of a kludge that was introduced without a commensurate format specifier in *printf, a failure that was only rectified in C99 and which could have been avoided altogether if they'd just not bothered with size_t in the first place. But of course we're stuck with it because sizeof yields it. > Leaving Windows aside, even 32-bit systems can easily have files bigger > than 2GB (though that was less likely back in 1990). Using something > similar to POSIX's off_t (a signed integer type, not to be confused with > the fpos_t type used by ISO C's fsetpos() and fgetpos()) would IMHO be > an improvement over using a *specific* predefined integer type like > long. I disagree because I think the plethora of types is a weakness rather than a strength of C, but I don't feel sufficiently strongly about it to want to fight you. :-) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-15 23:56 +0100 |
| Message-ID | <oacgl2$1bg$3@dont-email.me> |
| In reply to | #106145 |
Le 15/03/2017 à 17:52, Keith Thompson a écrit : > It's unlikely to break any > non-contrived user code, since implicit conversions will quietly > handle most inconsistencies. Thanks
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-03-15 16:33 +0000 |
| Message-ID | <oabq7l$rr1$2@dont-email.me> |
| In reply to | #106137 |
On 15/03/17 15:46, jacobnavia wrote: > Le 15/03/2017 à 16:25, Keith Thompson a écrit : >> jacobnavia <jacob@jacob.remcomp.fr> writes: >> [...] >>> As I told you before, fseeki64 doesn't exist in the 64 bit version and >>> has been replaced by fseek now, that returns a long long >> >> Do you mean long rather than long long? >> >> [...] >> > > No, I was speaking of the second argument of fseek actually. > The standard mandates long but I can't use that since it is 32 bits. The Standard doesn't give you any choice, if you want to remain conforming. > So I changed the function to use a long long and everything is OK, no > need for fseeki64 Everything is OK /if/ you no longer require the function to conform to ISO C. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-15 17:47 +0100 |
| Message-ID | <oabr0t$u19$1@dont-email.me> |
| In reply to | #106143 |
Le 15/03/2017 à 17:33, Richard Heathfield a écrit : > On 15/03/17 15:46, jacobnavia wrote: >> Le 15/03/2017 à 16:25, Keith Thompson a écrit : >>> jacobnavia <jacob@jacob.remcomp.fr> writes: >> So I changed the function to use a long long and everything is OK, no >> need for fseeki64 > > Everything is OK /if/ you no longer require the function to conform to > ISO C. > I do not want to go on with fseeki64, and make another non conforming function. Apparently the standard writers assumed that long would be 64 bits, or I do not know what they were thinking, ask them. In any case fseek works fine with the second argument a long long.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-15 10:04 -0700 |
| Message-ID | <lntw6uh3oy.fsf@kst-u.example.com> |
| In reply to | #106144 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 15/03/2017 à 17:33, Richard Heathfield a écrit :
>> On 15/03/17 15:46, jacobnavia wrote:
>>> Le 15/03/2017 à 16:25, Keith Thompson a écrit :
>>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>
>>> So I changed the function to use a long long and everything is OK, no
>>> need for fseeki64
>>
>> Everything is OK /if/ you no longer require the function to conform to
>> ISO C.
>
> I do not want to go on with fseeki64, and make another non conforming
> function. Apparently the standard writers assumed that long would be 64
> bits, or I do not know what they were thinking, ask them.
Microsoft, as I mentioned elsethread, uses _fseeki64. Since that name
is reserved for use at file scope, it's a conforming extension.
> In any case fseek works fine with the second argument a long long.
So you've decided that full conformance to the standard is not an
absolute requirement.
I'm not saying that's a bad thing, it's just something that I think
should be acknowledged. I encourage you to include a section in
your documentation that specifies where lcc-win does not conform
to the ISO C standard (perhaps you've already done so).
(Some of the non-ASCII characters in this followup might
not be represented correctly. jacob, your articles have
"charset=windows-1252" in their headers, and apparently my newsreader
doesn't recognize that character set. Would it be possible for
you to configure your newsreader to use UTF-8?)
--
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]
| From | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-16 00:52 +0100 |
| Message-ID | <oack40$1n5b$1@gioia.aioe.org> |
| In reply to | #106148 |
Le 15/03/2017 à 18:04, Keith Thompson a écrit : > (Some of the non-ASCII characters in this followup might > not be represented correctly. jacob, your articles have > "charset=windows-1252" in their headers, and apparently my newsreader > doesn't recognize that character set. Would it be possible for > you to configure your newsreader to use UTF-8?) I am not setting my messages to windows char set please. I am using a macintosh pro to post. You are receiving the text as sent by the news-eternal-september server. In my machine, the text of the message that I sent contains: Content-Type: text/plain; charset=utf-8; format=flowed Somewhere along the line that gets converted into windows charset. Please complain to those guys.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-15 18:02 -0700 |
| Message-ID | <ln8to6ghjm.fsf@kst-u.example.com> |
| In reply to | #106205 |
jacob navia <jacob@jacob.remcomp.fr> writes:
> Le 15/03/2017 à 18:04, Keith Thompson a écrit :
>> (Some of the non-ASCII characters in this followup might
>> not be represented correctly. jacob, your articles have
>> "charset=windows-1252" in their headers, and apparently my newsreader
>> doesn't recognize that character set. Would it be possible for
>> you to configure your newsreader to use UTF-8?)
>
> I am not setting my messages to windows char set please. I am using a
> macintosh pro to post. You are receiving the text as sent by the
> news-eternal-september server.
>
> In my machine, the text of the message that I sent contains:
>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>
> Somewhere along the line that gets converted into windows charset.
> Please complain to those guys.
Thank you for the information. (I imagine it could also be a problem at
aioe.org.)
--
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]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-15 18:23 -0700 |
| Message-ID | <ln4lyuggl1.fsf@kst-u.example.com> |
| In reply to | #106206 |
Keith Thompson <kst-u@mib.org> writes:
> jacob navia <jacob@jacob.remcomp.fr> writes:
>> Le 15/03/2017 à 18:04, Keith Thompson a écrit :
>>> (Some of the non-ASCII characters in this followup might
>>> not be represented correctly. jacob, your articles have
>>> "charset=windows-1252" in their headers, and apparently my newsreader
>>> doesn't recognize that character set. Would it be possible for
>>> you to configure your newsreader to use UTF-8?)
>>
>> I am not setting my messages to windows char set please. I am using a
>> macintosh pro to post. You are receiving the text as sent by the
>> news-eternal-september server.
>>
>> In my machine, the text of the message that I sent contains:
>>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>>
>> Somewhere along the line that gets converted into windows charset.
>> Please complain to those guys.
>
> Thank you for the information. (I imagine it could also be a problem at
> aioe.org.)
In fact the problem does seem to be at aioe.org. I see this header:
Content-Type: text/plain; charset=windows-1252; format=flowed
in your article when I view it on news.aioe.org, using both Gnus and
Thunderbird.
I'll post on aioe.news.helpdesk. I'll also look into figuring out how
to persuade Gnus to recognize Windows-1252.
--
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]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-17 13:45 -0700 |
| Message-ID | <lny3w3einz.fsf@kst-u.example.com> |
| In reply to | #106207 |
Keith Thompson <kst-u@mib.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> jacob navia <jacob@jacob.remcomp.fr> writes:
>>> Le 15/03/2017 à 18:04, Keith Thompson a écrit :
>>>> (Some of the non-ASCII characters in this followup might
>>>> not be represented correctly. jacob, your articles have
>>>> "charset=windows-1252" in their headers, and apparently my newsreader
>>>> doesn't recognize that character set. Would it be possible for
>>>> you to configure your newsreader to use UTF-8?)
>>>
>>> I am not setting my messages to windows char set please. I am using a
>>> macintosh pro to post. You are receiving the text as sent by the
>>> news-eternal-september server.
>>>
>>> In my machine, the text of the message that I sent contains:
>>>
>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>
>>>
>>> Somewhere along the line that gets converted into windows charset.
>>> Please complain to those guys.
>>
>> Thank you for the information. (I imagine it could also be a problem at
>> aioe.org.)
>
> In fact the problem does seem to be at aioe.org. I see this header:
>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> in your article when I view it on news.aioe.org, using both Gnus and
> Thunderbird.
>
> I'll post on aioe.news.helpdesk. I'll also look into figuring out how
> to persuade Gnus to recognize Windows-1252.
I've gotten a response on aioe.news.helpdesk, subject
Incorrect "charset=windows-1252" in header
(Those of you not using aioe won't be able to see the messages.)
The owner of the server indicates that the server doesn't change that
header, and that it must have had "charset=windows-1252" when it left
jacob's system. And yet jacob showed a header with "charset=utf-8",
which I presume he copy-and-pasted. I don't know what to think.
Incidentally, I've since noticed that a lot of other posters have
"charset=windows-1252" in their articles (perhaps because they post from
Windows?). I hadn't noticed because most of them only have ASCII
content, while jacob quite understandably uses some accented letters.
I'll continue looking into this, but not as a high priority.
I think getting Gnus to recognize windows-1252 is likely to be
the best solution.
--
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]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-18 00:23 +0100 |
| Message-ID | <oahr11$hh3$1@dont-email.me> |
| In reply to | #106391 |
Le 17/03/2017 à 21:45, Keith Thompson a écrit : > > I've gotten a response on aioe.news.helpdesk, subject > Incorrect "charset=windows-1252" in header > (Those of you not using aioe won't be able to see the messages.) > > The owner of the server indicates that the server doesn't change that > header, and that it must have had "charset=windows-1252" when it left > jacob's system. And yet jacob showed a header with "charset=utf-8", > which I presume he copy-and-pasted. I don't know what to think. > > Incidentally, I've since noticed that a lot of other posters have > "charset=windows-1252" in their articles (perhaps because they post from > Windows?). I hadn't noticed because most of them only have ASCII > content, while jacob quite understandably uses some accented letters. > > I'll continue looking into this, but not as a high priority. > I think getting Gnus to recognize windows-1252 is likely to be > the best solution. > Look I am sending you the message from User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Why should I use a windows charset? Because Thunderbird defaults in the news server to encoding in "Occidental". You have along list of languages (arab, chines whatever) and then "Occidental", what was the default. And look what? "Occidental" means in thunderbird "windows"!!! Mystery solved. I changed the encoding to UTF8, and maybe it will be better.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web