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

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

Re: What's the best hashing function?

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: What's the best hashing function? fir <profesor.fir@gmail.com> - 2015-09-16 09:35 -0700
    Re: What's the best hashing function? "D. Aaron Sawyer" <aaron@110.net> - 2015-09-16 14:22 -0300
      Re: What's the best hashing function? fir <profesor.fir@gmail.com> - 2015-09-16 10:59 -0700
        Re: What's the best hashing function? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-16 19:44 +0100
          Re: What's the best hashing function? fir <profesor.fir@gmail.com> - 2015-09-16 12:32 -0700
            Re: What's the best hashing function? Bartc <bc@freeuk.com> - 2015-09-16 20:40 +0100
              Re: What's the best hashing function? Keith Thompson <kst-u@mib.org> - 2015-09-16 13:11 -0700
              Re: What's the best hashing function? "James Harris" <james.harris.1@gmail.com> - 2015-09-16 21:16 +0100
                Re: What's the best hashing function? fir <profesor.fir@gmail.com> - 2015-09-16 13:47 -0700
                  Re: What's the best hashing function? fir <profesor.fir@gmail.com> - 2015-09-16 14:14 -0700
                Re: What's the best hashing function? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-16 18:08 -0500
                  Re: What's the best hashing function? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-17 00:13 +0100
                  Re: What's the best hashing function? fir <profesor.fir@gmail.com> - 2015-09-20 01:13 -0700
            Re: What's the best hashing function? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-16 13:10 -0700
            Re: What's the best hashing function? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-16 22:17 +0100
              Re: What's the best hashing function? fir <profesor.fir@gmail.com> - 2015-09-16 14:33 -0700
                Re: What's the best hashing function? fir <profesor.fir@gmail.com> - 2015-09-16 14:48 -0700
                  Re: What's the best hashing function? fir <profesor.fir@gmail.com> - 2015-09-16 14:58 -0700
                    Re: What's the best hashing function? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-16 18:13 -0500
                    Re: What's the best hashing function? supercat@casperkitty.com - 2015-09-16 16:29 -0700
                    Re: What's the best hashing function? David Brown <david.brown@hesbynett.no> - 2015-09-17 10:17 +0200
                      Re: What's the best hashing function? Keith Thompson <kst-u@mib.org> - 2015-09-17 08:53 -0700
                      Re: What's the best hashing function? supercat@casperkitty.com - 2015-09-17 11:29 -0700
                        Re: What's the best hashing function? David Brown <david.brown@hesbynett.no> - 2015-09-18 10:07 +0200
                          Re: What's the best hashing function? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-18 09:20 +0100
                          Re: What's the best hashing function? supercat@casperkitty.com - 2015-09-18 09:25 -0700
                            Re: What's the best hashing function? David Brown <david.brown@hesbynett.no> - 2015-09-18 19:45 +0200
                              Re: What's the best hashing function? supercat@casperkitty.com - 2015-09-18 11:47 -0700
                                Re: What's the best hashing function? David Brown <david.brown@hesbynett.no> - 2015-09-18 21:49 +0200
                                  Re: What's the best hashing function? supercat@casperkitty.com - 2015-09-18 14:50 -0700
                                    Re: What's the best hashing function? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-19 00:23 -0700
                                    Re: What's the best hashing function? David Brown <david.brown@hesbynett.no> - 2015-09-19 11:13 +0200
                                      Re: What's the best hashing function? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-19 11:03 +0100
                                        Re: What's the best hashing function? David Brown <david.brown@hesbynett.no> - 2015-09-19 12:38 +0200
                                      Re: What's the best hashing function? supercat@casperkitty.com - 2015-09-21 11:29 -0700
                                        Re: What's the best hashing function? David Brown <david.brown@hesbynett.no> - 2015-09-22 10:23 +0200
                                          Re: What's the best hashing function? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-22 02:31 -0700
                                            Re: What's the best hashing function? supercat@casperkitty.com - 2015-09-22 11:28 -0700
                                          Re: What's the best hashing function? supercat@casperkitty.com - 2015-09-22 11:18 -0700
                  Re: What's the best hashing function? David Brown <david.brown@hesbynett.no> - 2015-09-17 10:24 +0200
                    Re: What's the best hashing function? fir <profesor.fir@gmail.com> - 2015-09-17 01:48 -0700
                      Re: What's the best hashing function? fir <profesor.fir@gmail.com> - 2015-09-17 01:56 -0700
                      Re: What's the best hashing function? fir <profesor.fir@gmail.com> - 2015-09-17 02:09 -0700
              Re: What's the best hashing function? Keith Thompson <kst-u@mib.org> - 2015-09-16 14:49 -0700
                Re: What's the best hashing function? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-16 21:56 +0000
                Re: What's the best hashing function? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-16 23:37 +0100
          Re: What's the best hashing function? supercat@casperkitty.com - 2015-09-16 13:02 -0700
            Re: What's the best hashing function? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-16 21:57 +0100
              Re: What's the best hashing function? supercat@casperkitty.com - 2015-09-16 14:16 -0700
            Re: What's the best hashing function? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-16 21:57 +0000
              Re: What's the best hashing function? supercat@casperkitty.com - 2015-09-16 16:20 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#70781

W dniu czwartek, 17 września 2015 10:24:11 UTC+2 użytkownik David Brown napisał:
> On 16/09/15 23:48, fir wrote:
> > W dniu środa, 16 września 2015 23:33:49 UTC+2 użytkownik fir
> > napisał:
> >> W dniu środa, 16 września 2015 23:17:24 UTC+2 użytkownik Ben
> >> Bacarisse napisał:
> >>> fir <profesor.fir@gmail.com> writes: <snip>
> >>>>>>> On 2015.09.16 13:35, fir wrote:
> >>>>>>>> I encountered recently some example like this, Though i
> >>>>>>>> not tested it
> >>>>>>>> 
> >>>>>>>> its in jave i dont know what >>> means
> >>>>>>>> 
> >>>>>>>> /** Robert Jenkins' 96 bit Mix Function. */ private
> >>>>>>>> static int mix(int a, int b, int c) { a=a-b;  a=a-c;
> >>>>>>>> a=a^(c >>> 13); b=b-c;  b=b-a;  b=b^(a << 8); c=c-a;
> >>>>>>>> c=c-b;  c=c^(b >>> 13); a=a-b;  a=a-c;  a=a^(c >>>
> >>>>>>>> 12); b=b-c;  b=b-a;  b=b^(a << 16); c=c-a;  c=c-b;
> >>>>>>>> c=c^(b >>> 5); a=a-b;  a=a-c;  a=a^(c >>> 3); b=b-c;
> >>>>>>>> b=b-a;  b=b^(a << 10); c=c-a;  c=c-b;  c=c^(b >>> 15); 
> >>>>>>>> return c; }
> >>> <snip>
> >>>> so in short it means it is inpossible to revrite it to c?
> >>> 
> >>> No, that's not it at all.  It should be obvious that a C re-write
> >>> is possible.  The only question is how much effort do you want to
> >>> put in to make the code have *exactly* the same semantics on
> >>> *every* conforming C implementation.  The answer is none,
> >>> because, ironically, the original Jenkins hash function was
> >>> written C.  The Java re-write has been forced to use signed
> >>> integers (presumably it's old Java) and has therefore has altered
> >>> the semantics (though probably not at the bit-level).  Anyway, 
> >>> just use the original C version.
> >>> 
> >>> Or even use one of the newer hash function he's designed like: 
> >>> http://www.burtleburtle.net/bob/hash/spooky.html
> >>> 
> >> 
> >> aa-h, okay though if this particular example has its easy
> >> correspondent doesnt probably neccessary mean that all code that
> >> uses signed or unsigned shifts on negative integers can be
> >> revritten (and thats a bit worry - they should gave at least all
> >> those intrinsics in gcc if x86 supports it (and x86 afaik supports
> >> a wide wariety of shifts)
> >> 
> >> I vote for gcc intrinsics for all the x86 usable assembly to use
> >> (intrinsics should be probably standard term in c, as its great
> >> usability (not necessary 'portab;e' 9avaliable on all c targets,
> >> but as a platform dependant parts of stdlib or something (who said
> >> stdlib must be all portable) ) **
> >> 
> >> (** it all untill ev some more organisation will be done, as im not
> >> great fan of clib at all, but intrinsics are at least extreamly
> >> usable 'patch' for platforms (or seems so))
> > 
> > this is word on c standard (that maybe those people who care much
> > about standard should be interested maybe on this topic) ->
> > 
> > it is okay that c is designed to work on so wide variety of platforms
> > and thus has so many undefined parts ((though c has also iirc some
> > undefined parts that are not justified by different platform
> > behaviours - those maybe should be just defined))
> > 
> > but if so c should also probably standarize some platform dependant
> > parts by some groups of platforms 9it seems so), for example if the
> > talk is x86 platform or alike, there is need of standarisation those
> > outa-core-standard parts across gcc-vs-clang or what else; becouse if
> > no it is practically silly (behaviours that could be
> > agreed/coordinated on platforms are not..
> > 
> 
> There are far too many different platforms and targets for C for this to
> make sense.  And these days, C is a minor (but vitally important)
> language on x86, especially with Windows - while it is the biggest
> choice by far on embedded systems.  So gcc supports some 30+ target
> processors, and they have no interest in trying to make intrinsics for
> all opcodes on all platforms.  There is already a way to handle that -
> it's called assembly, with gcc inline assembly for mixing it with C code.
> 
> For many targets, gcc /does/ have intrinsics for some of the most
> commonly needed opcodes that are not easily expressed in C.  Thus there
> are intrinsics for a lot of SIMD stuff on x86, or atomic access
> instructions.
> 
> > - this leads admittedly to some c variants, like c-x86 c-something
> > other , but better that than nothing (probably))
> > 
> >

wack answer (only with smal positive dots/lines, like in 'Environment' things)

as to things im sayin, it is interesting that when present clib is in this portable
subset and for things not much needed , im saying for need of clib of platform specific and needed (yet difference is  clib is binaary code and i need 'intrinsic libs') (*)

(*) not saying if this is not only temporary solution

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

#70782

W dniu czwartek, 17 września 2015 10:48:58 UTC+2 użytkownik fir napisał:
> W dniu czwartek, 17 września 2015 10:24:11 UTC+2 użytkownik David Brown napisał:
> > On 16/09/15 23:48, fir wrote:
> > > W dniu środa, 16 września 2015 23:33:49 UTC+2 użytkownik fir
> > > napisał:
> > >> W dniu środa, 16 września 2015 23:17:24 UTC+2 użytkownik Ben
> > >> Bacarisse napisał:
> > >>> fir <profesor.fir@gmail.com> writes: <snip>
> > >>>>>>> On 2015.09.16 13:35, fir wrote:
> > >>>>>>>> I encountered recently some example like this, Though i
> > >>>>>>>> not tested it
> > >>>>>>>> 
> > >>>>>>>> its in jave i dont know what >>> means
> > >>>>>>>> 
> > >>>>>>>> /** Robert Jenkins' 96 bit Mix Function. */ private
> > >>>>>>>> static int mix(int a, int b, int c) { a=a-b;  a=a-c;
> > >>>>>>>> a=a^(c >>> 13); b=b-c;  b=b-a;  b=b^(a << 8); c=c-a;
> > >>>>>>>> c=c-b;  c=c^(b >>> 13); a=a-b;  a=a-c;  a=a^(c >>>
> > >>>>>>>> 12); b=b-c;  b=b-a;  b=b^(a << 16); c=c-a;  c=c-b;
> > >>>>>>>> c=c^(b >>> 5); a=a-b;  a=a-c;  a=a^(c >>> 3); b=b-c;
> > >>>>>>>> b=b-a;  b=b^(a << 10); c=c-a;  c=c-b;  c=c^(b >>> 15); 
> > >>>>>>>> return c; }
> > >>> <snip>
> > >>>> so in short it means it is inpossible to revrite it to c?
> > >>> 
> > >>> No, that's not it at all.  It should be obvious that a C re-write
> > >>> is possible.  The only question is how much effort do you want to
> > >>> put in to make the code have *exactly* the same semantics on
> > >>> *every* conforming C implementation.  The answer is none,
> > >>> because, ironically, the original Jenkins hash function was
> > >>> written C.  The Java re-write has been forced to use signed
> > >>> integers (presumably it's old Java) and has therefore has altered
> > >>> the semantics (though probably not at the bit-level).  Anyway, 
> > >>> just use the original C version.
> > >>> 
> > >>> Or even use one of the newer hash function he's designed like: 
> > >>> http://www.burtleburtle.net/bob/hash/spooky.html
> > >>> 
> > >> 
> > >> aa-h, okay though if this particular example has its easy
> > >> correspondent doesnt probably neccessary mean that all code that
> > >> uses signed or unsigned shifts on negative integers can be
> > >> revritten (and thats a bit worry - they should gave at least all
> > >> those intrinsics in gcc if x86 supports it (and x86 afaik supports
> > >> a wide wariety of shifts)
> > >> 
> > >> I vote for gcc intrinsics for all the x86 usable assembly to use
> > >> (intrinsics should be probably standard term in c, as its great
> > >> usability (not necessary 'portab;e' 9avaliable on all c targets,
> > >> but as a platform dependant parts of stdlib or something (who said
> > >> stdlib must be all portable) ) **
> > >> 
> > >> (** it all untill ev some more organisation will be done, as im not
> > >> great fan of clib at all, but intrinsics are at least extreamly
> > >> usable 'patch' for platforms (or seems so))
> > > 
> > > this is word on c standard (that maybe those people who care much
> > > about standard should be interested maybe on this topic) ->
> > > 
> > > it is okay that c is designed to work on so wide variety of platforms
> > > and thus has so many undefined parts ((though c has also iirc some
> > > undefined parts that are not justified by different platform
> > > behaviours - those maybe should be just defined))
> > > 
> > > but if so c should also probably standarize some platform dependant
> > > parts by some groups of platforms 9it seems so), for example if the
> > > talk is x86 platform or alike, there is need of standarisation those
> > > outa-core-standard parts across gcc-vs-clang or what else; becouse if
> > > no it is practically silly (behaviours that could be
> > > agreed/coordinated on platforms are not..
> > > 
> > 
> > There are far too many different platforms and targets for C for this to
> > make sense.  And these days, C is a minor (but vitally important)
> > language on x86, especially with Windows - while it is the biggest
> > choice by far on embedded systems.  So gcc supports some 30+ target
> > processors, and they have no interest in trying to make intrinsics for
> > all opcodes on all platforms.  There is already a way to handle that -
> > it's called assembly, with gcc inline assembly for mixing it with C code.
> > 
> > For many targets, gcc /does/ have intrinsics for some of the most
> > commonly needed opcodes that are not easily expressed in C.  Thus there
> > are intrinsics for a lot of SIMD stuff on x86, or atomic access
> > instructions.
> > 
> > > - this leads admittedly to some c variants, like c-x86 c-something
> > > other , but better that than nothing (probably))
> > > 
> > >
> 
> wack answer (only with smal positive dots/lines, like in 'Environment' things)
> 
> as to things im sayin, it is interesting that when present clib is in this portable
> subset and for things not much needed , im saying for need of clib of platform specific and needed (yet difference is  clib is binaary code and i need 'intrinsic libs') (*)
> 
> (*) not saying if this is not only temporary solution

practicaly it isnt probably big deal, as 
this platform extension can be expressed in headers language

programmer would have to chose if #include <x86> * and write and compile with whola set of platform specific intrinsics or if not include it and write in portable c

(* not saying that this is good name for platform, maybe some half beetween portable and x86 specyfic could be used for a wider subset of platforms etc for someone who want it)

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

#70784

(also not saying that i not miss some points on ideas on how c was established, but at least it is some partial view )

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

#70727

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
>                                       The Java re-write has been forced
> to use signed integers (presumably it's old Java) and has therefore has
> altered the semantics (though probably not at the bit-level).
[...]

That seems to imply that a newer version of Java suports unsigned
integer types, but as far as I can tell that's not the case (I just
checked the latest language specification, published this year).

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

#70729

Keith Thompson <kst-u@mib.org> wrote:

(snip)

> That seems to imply that a newer version of Java suports unsigned
> integer types, but as far as I can tell that's not the case (I just
> checked the latest language specification, published this year).

Last I knew, and as far back as I know, Java supports one unsigned
integer type of 16 bits.  Conveniently, or confusingly, called char.

-- glen

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

#70742

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>>                                       The Java re-write has been forced
>> to use signed integers (presumably it's old Java) and has therefore has
>> altered the semantics (though probably not at the bit-level).
> [...]
>
> That seems to imply that a newer version of Java suports unsigned
> integer types, but as far as I can tell that's not the case (I just
> checked the latest language specification, published this year).

Yes, you're right.  I was confusing the relatively new functions (added
in 1.8) that facilitate unsigned *arithmetic* with the presence of an
unsigned *type*.  There are now simple more ways to pretend that the
collection of bits in an int represent an unsigned number.

-- 
Ben.

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

#70690

On Wednesday, September 16, 2015 at 1:44:21 PM UTC-5, Ben Bacarisse wrote:
> If you are planning to translate the Java above into portable C, you
> should also know that the arithmetic operations might have undefined
> results due to overflow.

All arithmetic operations on unsigned types that are at least as large as
"unsigned int" have fully-defined behavior in all cases except for division
by zero, right-shifting in excess of the number of bits, or left-shifting in
excess of the number of bits; the latter three operations invoke Undefined
Behavior.

The only real "gotcha" from a portability perspective is that smaller
unsigned types smaller than "int" may get promoted to larger signed types.
In most cases, this will not affect anything, because the promotion will
usually expand the type enough to prevent any overflows from occurring, and
performing a sequence of additive, multiplicative, and bit-wise operations on
a signed type which is large enough not to overflow and then converting the
result to a smaller unsigned type will yield the same result as using the
unsigned type all along.  In some cases, however, calculations which would
have yielded fully-defined behavior when using unsigned types may yield
Undefined Behavior as a result of arithmetic promotions.  Consider, for
example, that on a system where `int` is 16 bits, the behavior of:

    uint16_t x = 65533;
    x*=x;

is fully defined, and will set x equal to 9, because unsigned multiplication
yields the lower bits of the result (the full multiplication would yield a
value of 0xFFFA0009, and the bottom 16 bits are 9).  On a system where `int`
is 32 bits, however, such code would yield Undefined Behavior, because the
uint16_t value would get promoted to an int32_t, and the product of 65533
times 65533 (i.e. 4294574089) is larger than the maximum value that "int" can
hold.  If the result of the multiplication were interpreted bit-wise as a
two's-complement number (which is what a lot of compilers will likely do),
the result of converting that to `uint16_t` would be 9, but the Standard does
not require compilers to behave in such fashion.  Some compilers would use
the overflow on the multiplication as an excuse to rewrite the meaning of
other parts of the code.  To avoid that, the latter statement must be written
as something like:

    x*=1u*x;

Compilers should hopefully refrain from generating any code for the multiply
by one, but the above code will ensure that x gets converted to an unsigned
type which is large enough to prevent any promotion to a signed type.

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

#70710

supercat@casperkitty.com writes:

> On Wednesday, September 16, 2015 at 1:44:21 PM UTC-5, Ben Bacarisse wrote:
>> If you are planning to translate the Java above into portable C, you
>> should also know that the arithmetic operations might have undefined
>> results due to overflow.
>
> All arithmetic operations on unsigned types that are at least as large as
> "unsigned int" have fully-defined behavior in all cases except for division
> by zero, right-shifting in excess of the number of bits, or left-shifting in
> excess of the number of bits; the latter three operations invoke Undefined
> Behavior.

Yes, that's exactly why I suggesting that a re-write in C should
probably use unsigned types.  The limited quoting makes your remark look
like a correction but, since you go on to give substantial detail, it
was probably intended as furthering the argument for using unsigned
types.

<snip>
-- 
Ben.

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

#70718

On Wednesday, September 16, 2015 at 3:58:07 PM UTC-5, Ben Bacarisse wrote:
> Yes, that's exactly why I suggesting that a re-write in C should
> probably use unsigned types.  The limited quoting makes your remark look
> like a correction but, since you go on to give substantial detail, it
> was probably intended as furthering the argument for using unsigned
> types.

Sorry I snipped too short.  You did correctly mention that unsigned types can
avoid Undefined Behavior, but failed to mention them important qualification
that unsigned types which are not at least as large as "unsigned int" may be
subject to unwanted promotion.  If compilers start using 64-bit "int" before
a standards-committee mandates that if the result of an additive,
multiplicative, or bitwise operator whose operands are unsigned values smaller
than "int" is cast or coerced to a type smaller than "int", the operands
shall be coerced to that type and the operator evaluated using that type.
There are no cases in which the Standard would presently mandate other
behavior, and I don't think such a rule would preclude any genuinely-useful
optimizations, but some compiler writers like to use any excuse they can find
to infer that programs won't receive certain inputs, and then use such
inferences to eliminate "unnecessary" code.

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

#70730

supercat@casperkitty.com wrote:

(snip)

> All arithmetic operations on unsigned types that are at least as large as
> "unsigned int" have fully-defined behavior in all cases except for division
> by zero, right-shifting in excess of the number of bits, or left-shifting in
> excess of the number of bits; the latter three operations invoke Undefined
> Behavior.

Make that equal to or in excess of the number of bits.

-- glen

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

#70749

On Wednesday, September 16, 2015 at 4:58:08 PM UTC-5, glen herrmannsfeldt wrote:
> supercat wrote:
> > All arithmetic operations on unsigned types that are at least as large as
> > "unsigned int" have fully-defined behavior in all cases except for division
> > by zero, right-shifting in excess of the number of bits, or left-shifting in
> > excess of the number of bits; the latter three operations invoke Undefined
> > Behavior.
> 
> Make that equal to or in excess of the number of bits.

When one factors all possibilities of padding bits, etc. the actual C rules
are rather absurdly complicated.  What C really needs to do is specify types
"uwrapN_t" which, when when defined, would be subject to promotions in the
same cases as `unsigned int` would on a system where that type had N value
bits and the corresponding `int` had one fewer, and unumN_t which, when
defined, would be required to auto-promote to a larger signed type.

A system where "int" and "int32_t" are synonymous could define "uwrap32_t"
and "uwrap64_t" as aliases to "uint32_t" and "uint64_t", respectively, and
"unum8_t" and "unum_16" as aliases to "uint8_t" and "uint16_t", respectively,
but a compiler for system where e.g. "int" was 64 bits, could legitimately
define a "uwrap32_t" type if it used compiler intrinsics for its fixed-size
integer types, and consequently had "unsignedness" dominate in cases where
a uwrap32_t was balanced with a type whose size was not explicitly specified
as being larger than 32 bits.

I would expect that 99% of code using unsigned integer types will in each
case either "want" operations to be performed as unsigned regardless of the
size of "int", want them to promote to signed regardless of the size of
"int", or not care about whether they are promoted or not.  I doubt there is
very much code which would want e.g. 32-bit unsigned values to behave as
uwrap32_t on some systems but as unum_32 on others, but unfortunately the
Standard doesn't have any unsigned integer types larger than 8 bits whose
behavior is independent of the size of "int".

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web