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

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

C89 compatibility question

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

Contents

  C89 compatibility question "Bill Cunningham" <nospam@nspam.invalid> - 2015-07-27 09:10 -0400
    Re: C89 compatibility question Philipp Klaus Krause <pkk@spth.de> - 2015-07-27 17:50 +0200
      Re: C89 compatibility question "Bill Cunningham" <nospam@nspam.invalid> - 2015-07-27 12:25 -0400
      Re: C89 compatibility question "Bill Cunningham" <nospam@nspam.invalid> - 2015-07-27 14:36 -0400
    Re: C89 compatibility question Thomas Richter <thor@math.tu-berlin.de> - 2015-07-27 19:54 +0200
      Re: C89 compatibility question "Bill Cunningham" <nospam@nspam.invalid> - 2015-07-27 14:23 -0400
        Re: C89 compatibility question Barry Schwarz <schwarzb@dqel.com> - 2015-07-27 17:24 -0700
          Re: C89 compatibility question "Bill Cunningham" <nospam@nspam.invalid> - 2015-07-28 13:57 -0400
      Re: C89 compatibility question "Bill Cunningham" <nospam@nspam.invalid> - 2015-07-27 14:27 -0400
    Re: C89 compatibility question Keith Thompson <kst-u@mib.org> - 2015-07-27 11:51 -0700
      Re: C89 compatibility question "Bill Cunningham" <nospam@nspam.invalid> - 2015-07-27 14:53 -0400
      Re: C89 compatibility question "Bill Cunningham" <nospam@nspam.invalid> - 2015-07-27 18:10 -0400
        Re: C89 compatibility question Keith Thompson <kst-u@mib.org> - 2015-07-27 16:22 -0700
          Re: C89 compatibility question "Bill Cunningham" <nospam@nspam.invalid> - 2015-07-28 09:28 -0400
            Re: C89 compatibility question Keith Thompson <kst-u@mib.org> - 2015-07-28 10:36 -0700

#66441 — C89 compatibility question

    I have this code so far to read a JFIF file and prehaps put it in a 
wrapper of sorts.

Struct JFIF_HEAD {
    uint8_t SOI={0xff,0xd8};

Not much I know. But I am already going to have to use stdint.h which is 
fine for me; but not C89. Is there an unsigned int that can be 8 bit in C89? 
The only thing in C89 I know of that is 8 bit is a char. If I remember 
correctly without going back and looking. I'm pretty confident I'm right.

    Could anything C89 replace uint8_t?

Bill

[toc] | [next] | [standalone]

#66447

On 27.07.2015 15:10, Bill Cunningham wrote:
>     I have this code so far to read a JFIF file and prehaps put it in a 
> wrapper of sorts.
> 
> Struct JFIF_HEAD {
>     uint8_t SOI={0xff,0xd8};
> 
> Not much I know. But I am already going to have to use stdint.h which is 
> fine for me; but not C89. Is there an unsigned int that can be 8 bit in C89? 
> The only thing in C89 I know of that is 8 bit is a char. If I remember 
> correctly without going back and looking. I'm pretty confident I'm right.
> 
>     Could anything C89 replace uint8_t?
> 
> Bill
> 
> 

You could use bitfields.

Philipp

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

#66448

"Philipp Klaus Krause" <pkk@spth.de> wrote in message 
news:mp5k0p$n7h$1@solani.org...

> You could use bitfields.

    Ok I am checking into this. I have never before heard of it.

Bill

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

#66453

"Philipp Klaus Krause" <pkk@spth.de> wrote in message 
news:mp5k0p$n7h$1@solani.org...

> You could use bitfields.

    I have this link.
http://www.tutorialspoint.com/cprogramming/c_bit_fields.htm

I'm a little confused as to why 2 1 byte elements of a struct take up 4 
bytes. But I will keep looking at this. Is this "bit field" thing only work 
in structs (or unions) ?

Bill

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

#66450

Am 27.07.2015 um 15:10 schrieb Bill Cunningham:
>      I have this code so far to read a JFIF file and prehaps put it in a
> wrapper of sorts.

Despite your question: If so, why don't you use readily available 
libraries for doing so?

>
> Struct JFIF_HEAD {
>      uint8_t SOI={0xff,0xd8};
>

How that should compile I'm unclear about. This looks like it is missing 
a [] behind SOI.

> Not much I know. But I am already going to have to use stdint.h which is
> fine for me; but not C89. Is there an unsigned int that can be 8 bit in C89?

In many if not most architectures, this is what "unsigned char" will do.

> The only thing in C89 I know of that is 8 bit is a char.

Nope. C89 does not ensure that. A char is anything the architecture can 
provide, with a range of at least -127 to 127 or 0 to 255, but it can be 
more. There are architectures where a char is the same size as an int, 
and 16 bit or even 32 bit. It does not even have to be a multiple of 8 
bits large. Actually, it does not even need to be a binary machine...

>      Could anything C89 replace uint8_t?

See above. For many architectures, "unsigned char" does, but it does not 
need to. Actually, on architectures where unsigned char is not 8 bit 
wide, it is also quite likely that uint8_t does not exist either.

IOW, you may not even want to bother for such architectures and use 
"unsigned char" right away.

Greetings,
	Thomas

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

#66451

"Thomas Richter" <thor@math.tu-berlin.de> wrote in message 
news:mp5r8t$925$1@news2.informatik.uni-stuttgart.de...
> Am 27.07.2015 um 15:10 schrieb Bill Cunningham:
>>      I have this code so far to read a JFIF file and prehaps put it in a
>> wrapper of sorts.
>
> Despite your question: If so, why don't you use readily available 
> libraries for doing so?

    I will want my own file signatures and such. And I might want to do more 
later than just a wrapper. For example, this code is to determine whether or 
not a file is raw or compressed. Or even non-standard. But I intend it to 
say also if a file is a JPEG and in the same family to see that and not deal 
with JPEGs.

>
>>
>> Struct JFIF_HEAD {
>>      uint8_t SOI={0xff,0xd8};
>>
>
> How that should compile I'm unclear about. This looks like it is missing a 
> [] behind SOI.

    Right. I forgot. It should be SOI[2]={0xff,0xd8};

>> Not much I know. But I am already going to have to use stdint.h which is
>> fine for me; but not C89. Is there an unsigned int that can be 8 bit in 
>> C89?
>
> In many if not most architectures, this is what "unsigned char" will do.

    But won't that force me into having to use ascii values? For example,

unsigned char SOI[2]={'0xff','0xd8'};

I will get ascii values here I am pretty sure. That's not what I want. I 
don't want a string either. That's a later member in this struct.

>> The only thing in C89 I know of that is 8 bit is a char.
>
> Nope. C89 does not ensure that. A char is anything the architecture can 
> provide, with a range of at least -127 to 127 or 0 to 255, but it can be 
> more. There are architectures where a char is the same size as an int, and 
> 16 bit or even 32 bit. It does not even have to be a multiple of 8 bits 
> large. Actually, it does not even need to be a binary machine...
>
>>      Could anything C89 replace uint8_t?
>
> See above. For many architectures, "unsigned char" does, but it does not 
> need to. Actually, on architectures where unsigned char is not 8 bit wide, 
> it is also quite likely that uint8_t does not exist either.
>
> IOW, you may not even want to bother for such architectures and use 
> "unsigned char" right away.
>
> Greetings,
> Thomas
>
> 

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

#66464

On Mon, 27 Jul 2015 14:23:55 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>
>"Thomas Richter" <thor@math.tu-berlin.de> wrote in message 
>news:mp5r8t$925$1@news2.informatik.uni-stuttgart.de...
>> Am 27.07.2015 um 15:10 schrieb Bill Cunningham:
>>> Struct JFIF_HEAD {
>>>      uint8_t SOI={0xff,0xd8};
>>>
>>
>> How that should compile I'm unclear about. This looks like it is missing a 
>> [] behind SOI.
>
>    Right. I forgot. It should be SOI[2]={0xff,0xd8};

Even with this change it is still a syntax error.  You have unbalanced
braces.  Did you mean
    struct JFIF_HEAD
       {
       uint8_t SOI[2];
       } a_struct_object_you_forgot_to_name = {0xff, 0xd8};
or did you mean
     struct JFIF_HEAD
       {
       uint8_t a_member_you_forgot_to_name;
        } SOI[2] = {0xff,0xd8};

Is there some reason you cannot compile your code before posting it
and copy/paste it correctly into your message?

-- 
Remove del for email

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

#66503

"Barry Schwarz" <schwarzb@dqel.com> wrote in message 
news:7cidrap9t9e0dpvf0rivn7n73pe1bci4ke@4ax.com...

[snip]

I thought everyone would know this was what I meant. I have much more to put 
into the struct before using it. Sorry.

> or did you mean
>     struct JFIF_HEAD
>       {
>       uint8_t a_member_you_forgot_to_name;
>        } SOI[2] = {0xff,0xd8};
>
> Is there some reason you cannot compile your code before posting it
> and copy/paste it correctly into your message?

Next would be
uint8_t EOI[2]={0xff,0xd9};

And the closing brace }

Bill

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

#66452

"Thomas Richter" <thor@math.tu-berlin.de> wrote in message 
news:mp5r8t$925$1@news2.informatik.uni-stuttgart.de...

> Despite your question: If so, why don't you use readily available 
> libraries for doing so?

    Oh and also. One can only learn C by doing. /Everything/ has been done 
before. In one way or another. This is a learning experience. ;)

Bill

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

#66457

"Bill Cunningham" <nospam@nspam.invalid> writes:
>     I have this code so far to read a JFIF file and prehaps put it in a 
> wrapper of sorts.
>
> Struct JFIF_HEAD {
>     uint8_t SOI={0xff,0xd8};

It's "struct", not "Struct".

> Not much I know. But I am already going to have to use stdint.h which is 
> fine for me; but not C89. Is there an unsigned int that can be 8 bit in C89? 
> The only thing in C89 I know of that is 8 bit is a char. If I remember 
> correctly without going back and looking. I'm pretty confident I'm right.
>
>     Could anything C89 replace uint8_t?

unsigned char is very likely to be the same as uint8_t.  It's not
guaranteed (which is why uint8_t was added by C99), but it's easily
checked by examining the value of UCHAR_MAX in <limits.h>.

There are C89-compatible implementations of <stdint.h>.  One of them is
here: http://www.lysator.liu.se/(nobg)/c/q8/index.html

Why are you restricted to C89?

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

#66458

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnoaixo2mt.fsf@kst-u.example.com...
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>     I have this code so far to read a JFIF file and prehaps put it in a
>> wrapper of sorts.
>>
>> Struct JFIF_HEAD {
>>     uint8_t SOI={0xff,0xd8};
>
> It's "struct", not "Struct".
>
>> Not much I know. But I am already going to have to use stdint.h which is
>> fine for me; but not C89. Is there an unsigned int that can be 8 bit in 
>> C89?
>> The only thing in C89 I know of that is 8 bit is a char. If I remember
>> correctly without going back and looking. I'm pretty confident I'm right.
>>
>>     Could anything C89 replace uint8_t?
>
> unsigned char is very likely to be the same as uint8_t.  It's not
> guaranteed (which is why uint8_t was added by C99), but it's easily
> checked by examining the value of UCHAR_MAX in <limits.h>.
>
> There are C89-compatible implementations of <stdint.h>.  One of them is
> here: http://www.lysator.liu.se/(nobg)/c/q8/index.html
>
> Why are you restricted to C89?

    I am not. If I wanted though to release the code, I don't know how many 
C99 compilers are out there. I definately know not many C11s.

Bill

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

#66459

    In my own gcc I have noticed I do not have the ISO header, float.h, or 
stdbool.h. There may be more lacking so my compiler is not fully ansi or iso 
compliant.

Bill

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

#66462

"Bill Cunningham" <nospam@nspam.invalid> writes:
>     In my own gcc I have noticed I do not have the ISO header, float.h, or 
> stdbool.h. There may be more lacking so my compiler is not fully ansi or iso 
> compliant.

How do you know they're missing?  The only way you can be sure they're
missing is by compiling a program that uses them.  Don't assume that the
files live in any specific location.

In particular, if "/usr/include/stdbool.h" doesn't exist, that doesn't
mean there's a problem.

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

#66491

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnk2tlnq33.fsf@kst-u.example.com...
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>     In my own gcc I have noticed I do not have the ISO header, float.h, 
>> or
>> stdbool.h. There may be more lacking so my compiler is not fully ansi or 
>> iso
>> compliant.
>
> How do you know they're missing?  The only way you can be sure they're
> missing is by compiling a program that uses them.  Don't assume that the
> files live in any specific location.
>
> In particular, if "/usr/include/stdbool.h" doesn't exist, that doesn't
> mean there's a problem.

    OK. Well I looked there. I didn't see them. It didn't occur to me they 
might be somewhere else. I've never tried to use float.h really either.

Bill

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

#66500

"Bill Cunningham" <nospam@nspam.invalid> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnk2tlnq33.fsf@kst-u.example.com...
>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>>     In my own gcc I have noticed I do not have the ISO header, float.h, 
>>> or
>>> stdbool.h. There may be more lacking so my compiler is not fully ansi or 
>>> iso
>>> compliant.
>>
>> How do you know they're missing?  The only way you can be sure they're
>> missing is by compiling a program that uses them.  Don't assume that the
>> files live in any specific location.
>>
>> In particular, if "/usr/include/stdbool.h" doesn't exist, that doesn't
>> mean there's a problem.
>
>     OK. Well I looked there. I didn't see them. It didn't occur to me they 
> might be somewhere else. I've never tried to use float.h really either.

The point is that the *compiler* knows where to find them.  If you try
to compile something with

    #include <stdbool.h>
    #include <float.h>

and the compiler complains that it can't find a header, then you've got
a problem.  Otherwise, there isn't.

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

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

csiph-web