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

Groups > comp.lang.c > #62472

Re: determines if it is a signed type

Show all headers | View raw

jadill33@gmail.com writes:

> On Thursday, May 21, 2015 at 5:48:49 PM UTC-4, Ben Bacarisse wrote:
>> jadill..@gmail.com writes:
<snip>
>> > If I have a file whose data maps to the format the stdint.h typedefs
>> > represent, I prefer to use those types to represent them in memory.
>> > I like to declare the structures in memory to follow the exact binary
>> > format in the file as much as I can.
>> 
>> Yes, but I don't see why that is important to you.
>
> Let me try to rephrase it with another example.  If I need to read a
> IEEE-754 float stored in its native binary representation from a file
> or packet, and I'm on a system where the native 'float' type is
> IEEE-754, and I define a type
>
> typedef float ieee754_float
>
> If I'm on a system where the IEEE-754 float is not the native
> representation of the type 'float', there won't be a ieee754_float
> typedef, and compiling the same code would result in a compiler
> error due to lack of a defined type.
>
> Would you have a problem if I had a function implementation that
> only uses the type ieee754_float to read the binary value straight
> from file?  That is my motivation to write binary I/O functions
> using uint32_t instead of unsigned long.  You may of course disagree
> with it, but does that communicate my point better?

I made what I think is the same point some posts ago -- if you don't
need to deal with "foreign" representations (the binary file matches
your system's type) then using uint32_t is fine.  If that was your point
why did your example not do this?  It read octets and put a value
calculated from them into a uint32_t, where an unsigned long would have
made the code (fractionally) more portable.

>> > Exactly what scenario are you imagining where uint_least32_t is available
>> > but not uint32_t?
>> 
>> Obviously I am imagining exactly a situation where unit32_t does not
>> exist (like a 36-bit machine for example).
>
> If I have a library of functions whose interface reads and writes
> stdint.h types, then the lack of availability of these types is a good
> indication that I need to do something special to handle these cases.

But if the code had used unsigned long, no changes would be needed at
all.  You want stdint.h to act as an assert, but it will fire in cases
where it need not fire.  Reading 32 bit into an unsigned long works
where uint32_t is not defined.

> Ideally I would not call file_read_uint32_le on a system that didn't
> define uint32_t, and if I did it would not compile.

I am still puzzled by why this would be ideal.

> I'd have to define
> something custom.

Not if the code used a universal type.  How do you feel about
uint_least32_t?

> That is why my binary I/O library of functions that
> I use for the most part are defined using types from stdint.h.

<snip>
>> > To ask the same question in a related way, do you
>> > use 'int' instead of 'bool' for boolean types, or do you define a
>> > wrapper for 'bool' in the case that the type definition doesn't exist?
>> 
>> I do both in different contexts.  I also use uint32_t at times.
>
> Okay.  I thought your point about using unsigned long was stronger than
> it actually is.

No, it's really very weak, but it's based on the almost zero costs of
using unsigned long.

<snip>
>> I think that re-writing your example to use unsigned long (and to remove
>> the hidden assumptions and undefined behaviour)...
>
> Can you point out the hidden assumptions and undefined behavior?  Honestly
> I don't know what they are.  What's hidden about uint32_t since the
> standard defines the binary representation?

uint8_t promotes to int, and you shift this promoted value in a way that
is not defined (and if int is 16 bits it goes wrong in other ways too)
so you are implicitly assuming that the undefined shift does what you
want, and that int is at least 32 bits.

C promotes types involved in most binary operations to a common type
where unsigned "trumps" signed, but this does not apply to shifts.
Instead, the left operand simply has the integer promotions applied.

> Do you not like the void*
> in the prototype and it should be declared with a uint32_t* parameter?
>
> bool file_read_uint32_le( uint32_t *p, FILE *stream );

I certainly prefer that (hiding the actual type behind a void * looks
like a bug waiting to happen) but it's not the main issue.

>> produces a function that
>> is just as useful, a little simpler, and ever so slightly more portable.
>> The result (an unsigned long) does not meet your criteria about matching
>> or reflecting the data, but it can represent the values and that, to me,
>> is more important.
>> 
>> > Okay, you say you're not claiming unsigned long is better in general,
>> > but you've spent quite a bit of time claiming that uint32_t is a poor
>> > choice of a data type, even for binary I/O in cases where the binary
>> > data matches the exact representation.  What qualifies as a valid use
>> > of uint32_t if binary I/O is not one of them?  Bit-field definitions?
>> 
>> No, you are completely misrepresenting my case.
>
> Okay, I thought you were making a stronger case not to use uint32_t in
> general that you were trying to make.  I still get the impression from
> our discussion that you think the types from stdint.h are not the best
> way to define functions to handle binary I/O for 2's complement, fixed
> width, no padding integers.  Am I misrepresenting your stance on this
> point?

Yes, to some extent that's a misrepresentation because I've tried to be
specific about the vague term "to handle".  There are kind of processing
(non-portable code, code that need only work is certain environments,
code that does not need to convert representations and so on) where
stdint.h types are a good choice.  There are other kinds of "handling"
where unsigned long trumps uint32_t because it needs no special support
and works everywhere.  It may be a tiny advantage in practice but when
the cost is zero, tiny advantages represent infinite cost/benefit gains!

BTW, it's not stdint.h specifically.  A lot of uses of uint32_t should,
in my option, really be uses of uint_least32_t which I don't mind at
all.  uint_least32_t is better than unsigned long in almost all cases
because it always exists and never wastes space unless space simply must
be wasted.

>> Reading a known-width
>> number from a binary file where you know the representation matches that
>> of the C implementation is a fine use of these types.
>
> This was the intended point of my original post, which is more clearly
> stated in your sentence here, and was the only point I was trying to
> make.

Ah.  That was obscured by your example.  Just be sure we are on the same
page about "representation" I mean that a simple fread into a uint32_t
would do.

>> You did not seem
>> to be suggesting that.  You gave an example that did not do that and did
>> not, as far as I could tell, benefit from the use of uint32_t.
>
> Are you referring to my original post, or the code snippet I used?

I'm not sure what you mean.  I am referring to the example that did more
than fread into a uint32_t.  If your original post intended to highlight
this simplest use of uint32_t, I certainly missed that point, but surely
I can be forgiven since you then posted and example of quite another
use.

-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web