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

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

determines if it is a signed type

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

Contents

  determines if it is a signed type asetofsymbols@gmail.com - 2015-05-17 10:07 -0700
    Re: determines if it is a signed type Richard Heathfield <rjh@cpax.org.uk> - 2015-05-17 18:12 +0100
      Re: determines if it is a signed type asetofsymbols@gmail.com - 2015-05-17 10:34 -0700
        Re: determines if it is a signed type asetofsymbols@gmail.com - 2015-05-17 11:09 -0700
        Re: determines if it is a signed type Kusalananda <kusalananda@example.com> - 2015-05-17 18:22 +0000
          Re: determines if it is a signed type asetofsymbols@gmail.com - 2015-05-17 11:31 -0700
            Re: determines if it is a signed type Kusalananda <kusalananda@example.com> - 2015-05-17 19:59 +0000
    Re: determines if it is a signed type Keith Thompson <kst-u@mib.org> - 2015-05-17 13:12 -0700
    Re: determines if it is a signed type Morris Dovey <mrdovey@iedu.com> - 2015-05-17 19:08 -0500
      Re: determines if it is a signed type Morris Dovey <mrdovey@iedu.com> - 2015-05-17 19:46 -0500
      Re: determines if it is a signed type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-18 01:59 +0100
        Re: determines if it is a signed type Morris Dovey <mrdovey@iedu.com> - 2015-05-17 20:10 -0500
        Re: determines if it is a signed type Keith Thompson <kst-u@mib.org> - 2015-05-18 00:37 -0700
          Re: determines if it is a signed type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-18 21:15 +0100
            Re: determines if it is a signed type Keith Thompson <kst-u@mib.org> - 2015-05-18 15:15 -0700
          Re: determines if it is a signed type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-18 21:51 +0000
            Re: determines if it is a signed type James Kuyper <jameskuyper@verizon.net> - 2015-05-18 18:00 -0400
        Re: determines if it is a signed type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-18 14:37 +0000
          Re: determines if it is a signed type jacobnavia <jacob@jacob.remcomp.fr> - 2015-05-18 17:09 +0200
            Re: determines if it is a signed type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-18 18:14 +0000
      Re: determines if it is a signed type Richard Heathfield <rjh@cpax.org.uk> - 2015-05-18 06:34 +0100
        Re: determines if it is a signed type Keith Thompson <kst-u@mib.org> - 2015-05-18 00:43 -0700
          Re: determines if it is a signed type Richard Heathfield <rjh@cpax.org.uk> - 2015-05-18 13:56 +0100
            Re: determines if it is a signed type Keith Thompson <kst-u@mib.org> - 2015-05-18 08:00 -0700
              Re: determines if it is a signed type Richard Heathfield <rjh@cpax.org.uk> - 2015-05-18 20:35 +0100
                Re: determines if it is a signed type jacobnavia <jacob@jacob.remcomp.fr> - 2015-05-18 23:08 +0200
                  Re: determines if it is a signed type Richard Heathfield <rjh@cpax.org.uk> - 2015-05-18 22:32 +0100
                    Re: determines if it is a signed type jacobnavia <jacob@jacob.remcomp.fr> - 2015-05-19 00:44 +0200
                      Re: determines if it is a signed type Richard Heathfield <rjh@cpax.org.uk> - 2015-05-19 00:05 +0100
                        Re: determines if it is a signed type jacobnavia <jacob@jacob.remcomp.fr> - 2015-05-19 01:43 +0200
                          Re: determines if it is a signed type Richard Heathfield <rjh@cpax.org.uk> - 2015-05-19 01:08 +0100
                            Re: determines if it is a signed type "Bartc" <bartc@freeuk.com> - 2015-05-19 11:33 +0100
                              Re: determines if it is a signed type Keith Thompson <kst-u@mib.org> - 2015-05-19 08:15 -0700
                                Re: determines if it is a signed type "Bartc" <bartc@freeuk.com> - 2015-05-19 19:36 +0100
                                  Re: determines if it is a signed type Keith Thompson <kst-u@mib.org> - 2015-05-19 11:55 -0700
                            Re: determines if it is a signed type jacobnavia <jacob@jacob.remcomp.fr> - 2015-05-19 11:39 +0200
                              Re: determines if it is a signed type "Bartc" <bartc@freeuk.com> - 2015-05-19 11:44 +0100
                                Re: determines if it is a signed type jacobnavia <jacob@jacob.remcomp.fr> - 2015-05-19 12:11 +0200
                              Re: determines if it is a signed type jadill33@gmail.com - 2015-05-19 05:45 -0700
                                Re: determines if it is a signed type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-19 15:03 +0100
                                  Re: determines if it is a signed type jadill33@gmail.com - 2015-05-19 08:46 -0700
                                    Re: determines if it is a signed type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-19 17:08 +0100
                                      Re: determines if it is a signed type jadill33@gmail.com - 2015-05-19 09:52 -0700
                                        Re: determines if it is a signed type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-19 20:36 +0100
                                          Re: determines if it is a signed type jadill33@gmail.com - 2015-05-20 07:40 -0700
                                            Re: determines if it is a signed type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-20 23:12 +0100
                                              Re: determines if it is a signed type jadill33@gmail.com - 2015-05-21 13:52 -0700
                                                Re: determines if it is a signed type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-21 22:48 +0100
                                                  Re: determines if it is a signed type jadill33@gmail.com - 2015-05-22 05:50 -0700
                                                    Re: determines if it is a signed type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-22 23:14 +0100
                                                      Re: determines if it is a signed type jadill33@gmail.com - 2015-05-26 14:31 -0700
                                            Re: determines if it is a signed type Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-22 23:32 -0700
                                  Re: determines if it is a signed type David Brown <david.brown@hesbynett.no> - 2015-05-20 12:26 +0200
                              Re: determines if it is a signed type Richard Heathfield <rjh@cpax.org.uk> - 2015-05-19 15:28 +0100
                                Re: determines if it is a signed type raltbos@xs4all.nl (Richard Bos) - 2015-05-23 10:37 +0000
                Re: determines if it is a signed type Keith Thompson <kst-u@mib.org> - 2015-05-18 15:21 -0700
                  Re: determines if it is a signed type Richard Heathfield <rjh@cpax.org.uk> - 2015-05-19 00:04 +0100
                    Re: determines if it is a signed type Keith Thompson <kst-u@mib.org> - 2015-05-19 08:03 -0700
                  Re: determines if it is a signed type David Brown <david.brown@hesbynett.no> - 2015-05-19 08:47 +0200
                    Re: determines if it is a signed type Keith Thompson <kst-u@mib.org> - 2015-05-19 08:07 -0700
            Re: determines if it is a signed type James Kuyper <jameskuyper@verizon.net> - 2015-05-18 11:28 -0400
      Re: determines if it is a signed type Keith Thompson <kst-u@mib.org> - 2015-05-18 00:40 -0700

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

#62211

On 18/05/15 01:08, Morris Dovey wrote:
> On 5/17/15 12:07 PM, asetofsymbols@gmail.com wrote:
>> Is there any better way?
>
> Of course - look at the declaration!

Or, for preference, the definition, since this will also tell you 
whether the object has actually been defined.

> If you’re too lazy to do that, you could try (untested)

If he's too lazy to look at the definition, he's probably too lazy to do 
something that takes effort to type and effort to think about.

OP: look at the definition. Really.

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

#62216

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 18/05/15 01:08, Morris Dovey wrote:
>> On 5/17/15 12:07 PM, asetofsymbols@gmail.com wrote:
>>> Is there any better way?
>>
>> Of course - look at the declaration!
>
> Or, for preference, the definition, since this will also tell you
> whether the object has actually been defined.
>
>> If you’re too lazy to do that, you could try (untested)
>
> If he's too lazy to look at the definition, he's probably too lazy to
> do something that takes effort to type and effort to think about.
>
> OP: look at the definition. Really.

How can I portably print the value returned by time(NULL)?  Looking at
the definition doesn't help.

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

#62217

On 18/05/15 08:43, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 18/05/15 01:08, Morris Dovey wrote:
>>> On 5/17/15 12:07 PM, asetofsymbols@gmail.com wrote:
>>>> Is there any better way?
>>>
>>> Of course - look at the declaration!
>>
>> Or, for preference, the definition, since this will also tell you
>> whether the object has actually been defined.
>>
>>> If you’re too lazy to do that, you could try (untested)
>>
>> If he's too lazy to look at the definition, he's probably too lazy to
>> do something that takes effort to type and effort to think about.
>>
>> OP: look at the definition. Really.
>
> How can I portably print the value returned by time(NULL)?  Looking at
> the definition doesn't help.

According to N1570, time() returns a time_t, which is a "real type". 
That means it could be an integer type or a floating point type. So the 
best we can do with time(NULL) in the absence of a time_t conversion 
specifier is to cast to the widest supported floating point type, 
presumably long double. We would do better to use gmtime or localtime 
followed by strftime to get a string in a reliable format, and then 
print that.

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

#62220

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 18/05/15 08:43, Keith Thompson wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> On 18/05/15 01:08, Morris Dovey wrote:
>>>> On 5/17/15 12:07 PM, asetofsymbols@gmail.com wrote:
>>>>> Is there any better way?
>>>>
>>>> Of course - look at the declaration!
>>>
>>> Or, for preference, the definition, since this will also tell you
>>> whether the object has actually been defined.
>>>
>>>> If you’re too lazy to do that, you could try (untested)
>>>
>>> If he's too lazy to look at the definition, he's probably too lazy to
>>> do something that takes effort to type and effort to think about.
>>>
>>> OP: look at the definition. Really.
>>
>> How can I portably print the value returned by time(NULL)?  Looking at
>> the definition doesn't help.
>
> According to N1570, time() returns a time_t, which is a "real
> type". That means it could be an integer type or a floating point
> type. So the best we can do with time(NULL) in the absence of a time_t
> conversion specifier is to cast to the widest supported floating point
> type, presumably long double. We would do better to use gmtime or
> localtime followed by strftime to get a string in a reliable format,
> and then print that.

Converting a long long to long double can lose information.

The best we can do is this:

#include <stdio.h>
#include <time.h>
#include <stdint.h>

int main(void) {
    time_t now = time(NULL);

    if ((time_t)-1 > 0) {
        // time_t is unsigned
        printf("%ju\n", (uintmax_t)now);
    }
    else if ((time_t)1 / 2 == 0) {
        // time_t is signed
        printf("%jd\n", (intmax_t)now);
    }
    else {
        // time_t is floating-point
        printf("%Lf\n", (long double)now);
    }
}

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

#62242

On 18/05/15 16:00, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 18/05/15 08:43, Keith Thompson wrote:
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>> On 18/05/15 01:08, Morris Dovey wrote:
>>>>> On 5/17/15 12:07 PM, asetofsymbols@gmail.com wrote:
>>>>>> Is there any better way?
>>>>>
>>>>> Of course - look at the declaration!
>>>>
>>>> Or, for preference, the definition, since this will also tell you
>>>> whether the object has actually been defined.
>>>>
>>>>> If you’re too lazy to do that, you could try (untested)
>>>>
>>>> If he's too lazy to look at the definition, he's probably too lazy to
>>>> do something that takes effort to type and effort to think about.
>>>>
>>>> OP: look at the definition. Really.
>>>
>>> How can I portably print the value returned by time(NULL)?  Looking at
>>> the definition doesn't help.
>>
>> According to N1570, time() returns a time_t, which is a "real
>> type". That means it could be an integer type or a floating point
>> type. So the best we can do with time(NULL) in the absence of a time_t
>> conversion specifier is to cast to the widest supported floating point
>> type, presumably long double. We would do better to use gmtime or
>> localtime followed by strftime to get a string in a reliable format,
>> and then print that.
>
> Converting a long long to long double can lose information.

Granted, although I must confess that I'm not terribly cut up about the 
fact. If the implementation is reporting a time_t so colossal that it 
cannot accurately be represented in a long double, then it's probably a 
DS9K variant anyway.

> The best we can do is this:
>
> #include <stdio.h>
> #include <time.h>
> #include <stdint.h>

Sorry, I thought you said "portably"? If you #include <stdint.h>, you 
immediately lose portability to older C implementations.

I realise that this is a price you have decided you are prepared to pay, 
but not everyone is in that position.

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

#62247

Le 18/05/2015 21:35, Richard Heathfield a écrit :
>> The best we can do is this:
>>
>> #include <stdio.h>
>> #include <time.h>
>> #include <stdint.h>
>
> Sorry, I thought you said "portably"? If you #include <stdint.h>, you
> immediately lose portability to older C implementations.
>
> I realise that this is a price you have decided you are prepared to pay,
> but not everyone is in that position.
>

There are many public domain "stdint.h" implementations. Apparently you 
do not know them, or they do not exist for your platform, an "older C 
implementation".

That's very easy to solve. You write your own stdint.h (just a 15 minute 
work) and you are done...

Actually, it is possible to write all of C99 in C89, OF COURSE!

C89 is a perfectly general purpose language. You can write *ANYTHING* 
with it, C99 included. Granted, there are some things that are better 
done by the compiler system. But for "stdint.h" there is really NO 
problem in porting your code to C99...

It is a file that *renames* some existing types into new portable names, 
and if you just write a quick fix for your implementation and the 
standard int types that you use, this is very easy.

Advantages:

Your code is more portable. You are now dependent on C89, an obsolete 
standard, more and more difficult to obtain as time passes. The solution 
is to fix things like stdint.h in your implementation yourself.

Freed from the C89 dependency, your code is more portable.

Disadvantages:

You have to work 15 minutes. Yes, I know, it is a chore, you would have 
to add a set of files that you use in all your projects:

C89toC99

where you put stdint.h and other useful goodies written in C89.

jacob

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

#62248

On 18/05/15 22:08, jacobnavia wrote:
> Le 18/05/2015 21:35, Richard Heathfield a écrit :
>>> The best we can do is this:
>>>
>>> #include <stdio.h>
>>> #include <time.h>
>>> #include <stdint.h>
>>
>> Sorry, I thought you said "portably"? If you #include <stdint.h>, you
>> immediately lose portability to older C implementations.
>>
>> I realise that this is a price you have decided you are prepared to pay,
>> but not everyone is in that position.
>>
>
> There are many public domain "stdint.h" implementations. Apparently you
> do not know them, or they do not exist for your platform, an "older C
> implementation".

My development platform is whichever machine and implementation I happen 
to be writing code on. That varies. My target platforms are whichever 
machines and implementations are in use by the people for whom my code 
is intended. That varies too, and it is in fact beyond my control 
(except insofar as I can reduce the number of people who can use the 
code by limiting its portability).

> That's very easy to solve. You write your own stdint.h (just a 15 minute
> work) and you are done...

An implementor is in the happy position of knowing what platform(s) he 
supports, and can write his stdint.h accordingly, which is why it might 
indeed only take him 15 minutes to do it. I think it would take longer 
than 15 minutes to write a stdint.h that would be correct for any 
conceivable ISO C platform.

<snip>

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

#62258

Le 18/05/2015 23:32, Richard Heathfield a écrit :
> I think it would take longer than 15 minutes to write a stdint.h that
> would be correct for any conceivable ISO C platform.

Yes, but you do not need "any conceivable platform", you need a stdint.h 
that is OK for the platform you are using.

Mostly you can classify them in:

64 bit, 32 bit and 16 bit.

There are a few variations and once you have written it, it takes only 2 
minutes editing to write it for another platform...

And in MOST platforms there is a C99 compiler already there. If it is 
gcc you can use their stdint.h as a template.

Please do not drown in a cup of tea...

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

#62263

On 18/05/15 23:44, jacobnavia wrote:
> Le 18/05/2015 23:32, Richard Heathfield a écrit :
>> I think it would take longer than 15 minutes to write a stdint.h that
>> would be correct for any conceivable ISO C platform.
>
> Yes, but you do not need "any conceivable platform", you need a stdint.h
> that is OK for the platform you are using.

Sorry, but "OK for the platform you are using" leads me to think that 
you may have missed the point of my earlier article.

<snip>

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

#62265

Le 19/05/2015 01:05, Richard Heathfield a écrit :
> Sorry, but "OK for the platform you are using" leads me to think that
> you may have missed the point of my earlier article.

No because you said

My development platform is whichever machine and implementation I happen 
to be writing code on. That varies. My target platforms are whichever 
machines and implementations are in use by the people for whom my code 
is intended. That varies too, and it is in fact beyond my control 
(except insofar as I can reduce the number of people who can use the 
code by limiting its portability).

How do you use int32_t TODAY?

Suppose that you are writing a hash table that needs to hold at least 
1Giga records. You need uint32_t to index it.

Then, you will write

typedef unsigned long uint32_t;

in SOME platforms. In others you will write

typedef unsigned int uint32_t;

That is stdint.h. You are doing it TODAY when you need portable types of 
a specific bit size. Any serious code uses bitsize dependent code 
anyway. You suppose that any data structure index will need to go beyond 
65535 in some cases isn't it?

Or are all your programs assuming unsigned int from zero to 65535?

Because if not they are NOT portable to 16 Bit systems what is MUCH more 
serious that stdint.h.

For REAL software systems you get paid for, I mean. Not some toy system 
in DS9.

jacob

P.S. And besides, how do you write your functions?

int fn(a,b)
int a; double b;
{
}

Are you excluding K&R people???


:-)

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

#62266

On 19/05/15 00:43, jacobnavia wrote:
> Le 19/05/2015 01:05, Richard Heathfield a écrit :
>> Sorry, but "OK for the platform you are using" leads me to think that
>> you may have missed the point of my earlier article.
>
> No because you said
>
> My development platform is whichever machine and implementation I happen
> to be writing code on. That varies. My target platforms are whichever
> machines and implementations are in use by the people for whom my code
> is intended. That varies too, and it is in fact beyond my control
> (except insofar as I can reduce the number of people who can use the
> code by limiting its portability).

Right.

> How do you use int32_t TODAY?

I don't.

> Suppose that you are writing a hash table that needs to hold at least
> 1Giga records. You need uint32_t to index it.

Actually, unsigned long will do fine (although if I need that many 
records I should really be using a database).

> Then, you will write
>
> typedef unsigned long uint32_t;
>
> in SOME platforms. In others you will write
>
> typedef unsigned int uint32_t;

So either I write a separate header for each platform, and ship *all* 
the headers so that people using my code can scratch their heads trying 
to work out which one to use, or I write one header that is littered 
with #if this and #ifdef that and I have no guarantee that I've covered 
all the bases... or I can just write the code to use unsigned long and 
be done with it. I find the last of these courses to be the simplest and 
most elegant.

> That is stdint.h. You are doing it TODAY when you need portable types of
> a specific bit size. Any serious code uses bitsize dependent code
> anyway. You suppose that any data structure index will need to go beyond
> 65535 in some cases isn't it?
>
> Or are all your programs assuming unsigned int from zero to 65535?

I don't have to assume that unsigned int has *at least* that range, 
because it's guaranteed. I don't assume that it has *only* that range.

> P.S. And besides, how do you write your functions?
>
> int fn(a,b)
> int a; double b;
> {
> }
>
> Are you excluding K&R people???

Yes. I try to make very few assumptions about target platforms, but I do 
assume a compiler that conforms to ISO C (at least one of 90, 95, 99, 11).

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

#62280

"Richard Heathfield" <rjh@cpax.org.uk> wrote in message
news:mjdurg$2qu$1@dont-email.me...
> On 19/05/15 00:43, jacobnavia wrote:
>

>> How do you use int32_t TODAY?
>
> I don't.
>
>> Suppose that you are writing a hash table that needs to hold at least
>> 1Giga records. You need uint32_t to index it.
>
> Actually, unsigned long will do fine (although if I need that many records
> I should really be using a database).
>
>> Then, you will write
>>
>> typedef unsigned long uint32_t;
>>
>> in SOME platforms. In others you will write
>>
>> typedef unsigned int uint32_t;
>
> So either I write a separate header for each platform, and ship *all* the
> headers so that people using my code can scratch their heads trying to
> work out which one to use, or I write one header that is littered with #if
> this and #ifdef that and I have no guarantee that I've covered all the
> bases... or I can just write the code to use unsigned long and be done
> with it. I find the last of these courses to be the simplest and most
> elegant.

I have the same problem to solve: expressing a particular width of int type,
on C platforms where the widths can vary widely.

int is usually 32 bits, but can be 16 and even 64.

long int might be 32 bits in some places, and 64 bits in others.

(And then you have platforms with odd int sizes anyway but that's of less
interest these days.)

Only long long int might be expected to be at least 64 bits. It's a bit of a
mess really, so it's not surprising that stdint.h was introduced. I suspect
partly because people were writing their own incompatible specific width
types on top of the the built-in types, and it was the names they chose that
was the problem.

The C code I 'write' now is largely auto-generated, so I use my own scheme
too: i32, u32 and so on (partly to keep output files more compact). That
relies on *one* header file to define those. I think at the moment that
header file makes use of stdint.h,  but if it has to be changed, it's in
only one place.

(I have to use specific width types because the source language has the
ability to specify them and they have to be represented properly. It is also
necessary for the translator to know what actual widths are being used, but
without knowing exactly which C compiler might be used (or C might not even
be a target), using u64 etc is a safer bet.

Actually it could do with knowing the size of pointer types too, as that is
also important, but I don't think C allows you to specify a short or long
pointer; it only gives you one size per platform/per target architecture. So
I have to say the target has to be C-32 or C-64. Maybe I should add an
'assert' to test this in the generated C.)

-- 
Bartc

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

#62289

"Bartc" <bartc@freeuk.com> writes:
[...]
> The C code I 'write' now is largely auto-generated, so I use my own scheme
> too: i32, u32 and so on (partly to keep output files more compact). That
> relies on *one* header file to define those. I think at the moment that
> header file makes use of stdint.h,  but if it has to be changed, it's in
> only one place.

Is using slightly shorter names like i32 rather than standard names
like int32_t really all that helpful?

If you need fixed-size types, I can think of no good reason to
use names other than the ones defined in <stdint.h>.  If you're
stuck using a C implementation that doesn't support <stdint.h>
(and some pre-C99 implementations do support it as an extension),
you can use Doug Gwyn's public-domain "q8" files:

    http://www.lysator.liu.se/%28nobg%29/c/q8/index.html

(The requirements on the representations of the fixed-size types in
<stdint.h> are perhaps more strict than they need to be.  Practically
speaking, I don't consider that a good reason not to use them.)

[...]

> Actually it could do with knowing the size of pointer types too, as that is
> also important, but I don't think C allows you to specify a short or long
> pointer; it only gives you one size per platform/per target architecture. So
> I have to say the target has to be C-32 or C-64. Maybe I should add an
> 'assert' to test this in the generated C.)

C doesn't let you specify the size of a pointer, and it doesn't
guarantee that different pointer types have the same size.

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

#62310

"Keith Thompson" <kst-u@mib.org> wrote in message
news:874mn84mzk.fsf@kst-u.example.com...
> "Bartc" <bartc@freeuk.com> writes:
> [...]
>> The C code I 'write' now is largely auto-generated, so I use my own
>> scheme
>> too: i32, u32 and so on (partly to keep output files more compact). That
>> relies on *one* header file to define those. I think at the moment that
>> header file makes use of stdint.h,  but if it has to be changed, it's in
>> only one place.
>
> Is using slightly shorter names like i32 rather than standard names
> like int32_t really all that helpful?

Yes, because I'm adding an extra level of indirection. Usually i32 will map
to int32_t, but I like the ability to easily override  it (I can't give you
reasons, but sooner or later the need will arise).

Also these names are part of a consistent naming convention, not all of
which have been defined in stdint.h, such as r64 (double), c8 (signed char),
and c32 (uint32_t rather than a wide char type).

(c8 is considered an unsigned type in the source language, but making use of
explicit unsigned can give strange problems in C compilers. But I normally
use a 'byte' type (also called u8, which maps to uint_8) for small integers
to bypass some of those problems, with c8 used for chars and strings mostly.

This might also be an example where c8 could be experimentally redefined as
unsigned char to see what happens, by changing one line instead of the more
difficult alternatives.)

>> Actually it could do with knowing the size of pointer types too, as that
>> is
>> also important, but I don't think C allows you to specify a short or long
>> pointer; it only gives you one size per platform/per target architecture.
>> So
>> I have to say the target has to be C-32 or C-64. Maybe I should add an
>> 'assert' to test this in the generated C.)
>
> C doesn't let you specify the size of a pointer, and it doesn't
> guarantee that different pointer types have the same size.

Whatever the size of intptr_t is, that's what I mean. On the platforms I'm
working on, it will be 32 or 64 bits. The source language which is
translated into C only has one size of pointer (anything different that
comes along will be a different type, which will be another parameter
associated with the target language).

-- 
Bartc

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

#62316

"Bartc" <bartc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:874mn84mzk.fsf@kst-u.example.com...
>> "Bartc" <bartc@freeuk.com> writes:
>> [...]
>>> The C code I 'write' now is largely auto-generated, so I use my own
>>> scheme
>>> too: i32, u32 and so on (partly to keep output files more compact). That
>>> relies on *one* header file to define those. I think at the moment that
>>> header file makes use of stdint.h,  but if it has to be changed, it's in
>>> only one place.
>>
>> Is using slightly shorter names like i32 rather than standard names
>> like int32_t really all that helpful?
>
> Yes, because I'm adding an extra level of indirection. Usually i32 will map
> to int32_t, but I like the ability to easily override  it (I can't give you
> reasons, but sooner or later the need will arise).

It would be interesting to see a real-world case where you'd want to
define i32 as something other than int32_t.  I can think of a couple of
possible reasons: your C implementation doesn't support <stdint.h> (but
that's easy to work around), or your target system isn't 2's-complement
and/or uses padding bits (I'd expect that to be very rare).

> Also these names are part of a consistent naming convention, not all of
> which have been defined in stdint.h, such as r64 (double), c8 (signed char),
> and c32 (uint32_t rather than a wide char type).

Ok, that's a decent reason.  I'd probably choose to base my naming
convention on the one used in <stdint.h>, but that's not a strong
argument.

[...]

>> C doesn't let you specify the size of a pointer, and it doesn't
>> guarantee that different pointer types have the same size.
>
> Whatever the size of intptr_t is, that's what I mean. On the platforms I'm
> working on, it will be 32 or 64 bits. The source language which is
> translated into C only has one size of pointer (anything different that
> comes along will be a different type, which will be another parameter
> associated with the target language).

intptr_t is probably, but not certainly, going to be the same size as
void*, and therefore as char*.  (It's at least wide enough to hold all
the information needed to recreate a void* value.)

I meant to mention that if you want to assume all C pointer types are
the same size, you're relying on assumptions that aren't guaranteed by
the standard, but that's not necessariliy a bad thing if there's a
non-zero benefit.  One of C's greatest strengths is the ability to use
it to write *non-portable* code.  All else being equal, I prefer
portability -- but all else is not always equal.

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

#62281

Le 19/05/2015 02:08, Richard Heathfield a écrit :
> unsigned long will do fine

In most versions of linux that will be 64 bits. If yu need to be able to 
index just 10000 records you are wasting 4 bytes. If you need binary 
compatibility of the output of a program then you can't do that.

But I do not want to convince you.
You want to stay in C89? Fine with me.

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

#62282

"jacobnavia" <jacob@jacob.remcomp.fr> wrote in message 
news:mjf09m$v63$1@dont-email.me...
> Le 19/05/2015 02:08, Richard Heathfield a écrit :
>> unsigned long will do fine
>
> In most versions of linux that will be 64 bits. If yu need to be able to 
> index just 10000 records you are wasting 4 bytes.

Or 100,000 records. With 10,000, he would just use int; it doesn't even need 
to be unsigned.

-- 
Bartc 

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

#62283

Le 19/05/2015 12:44, Bartc a écrit :
> "jacobnavia" <jacob@jacob.remcomp.fr> wrote in message
> news:mjf09m$v63$1@dont-email.me...
>> Le 19/05/2015 02:08, Richard Heathfield a écrit :
>>> unsigned long will do fine
>>
>> In most versions of linux that will be 64 bits. If yu need to be able to
>> index just 10000 records you are wasting 4 bytes.
>
> Or 100,000 records. With 10,000, he would just use int; it doesn't even need
> to be unsigned.
>

`Yes, I misstyped.

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

#62284

On Tuesday, May 19, 2015 at 5:39:13 AM UTC-4, jacobnavia wrote:
> Le 19/05/2015 02:08, Richard Heathfield a écrit :
> > unsigned long will do fine
> 
> In most versions of linux that will be 64 bits. If yu need to be able to 
> index just 10000 records you are wasting 4 bytes. If you need binary 
> compatibility of the output of a program then you can't do that.
> 
> But I do not want to convince you.
> You want to stay in C89? Fine with me.

Yeah, one of the strongest motivations to use stdint.h is reading/writing
binary protocols in files/sockets.  You'll be hard pressed to avoid
problems on multiple platforms without using some mechanism for
defining fixed width types, and stdint.h is well, the standard way
of defining the names of those types.

I feel that C90 without some kind of stdint.h wrapper is not well poised
to handle this problem space.

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

#62285

jadill33@gmail.com writes:

> On Tuesday, May 19, 2015 at 5:39:13 AM UTC-4, jacobnavia wrote:
>> Le 19/05/2015 02:08, Richard Heathfield a écrit :
>> > unsigned long will do fine
>> 
>> In most versions of linux that will be 64 bits. If yu need to be able to 
>> index just 10000 records you are wasting 4 bytes. If you need binary 
>> compatibility of the output of a program then you can't do that.
>> 
>> But I do not want to convince you.
>> You want to stay in C89? Fine with me.
>
> Yeah, one of the strongest motivations to use stdint.h is reading/writing
> binary protocols in files/sockets.  You'll be hard pressed to avoid
> problems on multiple platforms without using some mechanism for
> defining fixed width types, and stdint.h is well, the standard way
> of defining the names of those types.

The exact-width types from stdint.h barely scratch the surface of this
problem.  There are representation issues (endianness being the most
common) and packing/alignment issues if you hope to use exact-width
types to define a struct you can just fread.

And when you have to deal with these issues the simplest solution is
very often to store the result in native types (or to use the
u?int_leastN_t types from stdint.h), quite possibly in a structure that
does not map onto the protocol bytes at all.

> I feel that C90 without some kind of stdint.h wrapper is not well poised
> to handle this problem space.

That's not been my experience, unless you interpret the wrapper as being
very thin indeed.  About the only really useful typedef is for something
a bit like int_least32_t since you can't assume int can store 32 bits
and you may not be prepared to pay the cost of using long.

-- 
Ben.

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

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

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

csiph-web