In article <347d93$lfd@dawn.mmm.com> hopps@mmm.com (Kevin J Hopps)
writes:

|> Stan Friesen (swf@ElSegundoCA.NCR.COM) wrote:
|> > In article <1994Aug31.083244.27454@news.unige.ch>, favre@medsun.unige.ch (Eric Favre) writes:
|> > |> In article <3416t8$r3b@vixen.cso.uiuc.edu>, db3565@ehsn13.cen.uiuc.edu (David G Baranec) writes:
|> > |> |> 1. The header for a TGA file requires that you write a 2 byte field. In DOS,
|> > |> |> this is no problem as an int type is 2 bytes. In Unix, this isn't the case.
|> > |> |> So, what should I use to write this field to the disk?
|> > |>
|> > |> short: 2 bytes
|> > |> long:  4 bytes
|> > |> int:   2 bytes with DOS, and 4 bytes with most UNIX systems

|> > This is not guarenteed.  What is guarenteed is that short is *at* *least*
|> > 2 bytes - which is not what is wanted.  The only *portable* way to do this
|> > is as follows:

|> >  unsigned val;
|> >  fputc(val&0xff, ofp);
|> >  fputc(val>>8, ofp);

|> To be pedantic, I think this is not correct.  What I read in the ARM is
|> that the minimum acceptible value for UINT_MAX is 65535.  It says nothing
|> about bytes.  On a mainframe with 36 bit words, it is conceivable that
|> an unsigned would be 18 bits, making UINT_MAX 262143.

Actually, you are right.  I should have been more specific.

In my own code, the above is (not surprisingly) encapsulated in a
function.  This function asserts that val <= 65535 before starting.

I do this because 65535 is the largest value which can be *portably*
written to an unsigned int.  I very explicitly use 65535 instead of
UINT_MAX or USHRT_MAX.  Thus, even on machines which support more, I
impose this restriction for data which will be written to an external
data support (disk, or a transmission line).  (In the case of the
previous problem, the user was clearly talking about an unsigned value
of two octets, and not about C/C++ bytes/unsigned's, etc.)

|> This also raises [acedemic] questions about whether using 0xff and 8 in
|> your code offers any kind of guarantee.

It offers the guarentee that it will be compatible to all conforming
implementations.  The standard requires that a char be at least 8
bits; my implementation refuses to use more, even if the underlying
implementation supports it.

This is an intentional decision; in most cases, I would use CHAR_BIT,
and ~(~0 << CHAR_BIT).

My encapsulated read/write functions however, are designed not only to
be portable themselves, but for the data they write to be portable.
They *always* write (and read) low order byte first, so they are
indifferent to the endian-ness of the machine.  The versions for
signed values always write (and read) signed magnitude notation
(because I found this the easiest to write portably), so they are
indifferent to the notation used for signed values.

Luckily, I've never had the problem of transmitting floating point
values.  I'd hate to try and write a portable routine for that (which
doesn't cause unnecessary precision loss).
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <1994Aug31.083244.27454@news.unige.ch>, favre@medsun.unige.ch (Eric Favre) writes:
|> In article <3416t8$r3b@vixen.cso.uiuc.edu>, db3565@ehsn13.cen.uiuc.edu (David G Baranec) writes:
|> |> 1. The header for a TGA file requires that you write a 2 byte field. In DOS,
|> |> this is no problem as an int type is 2 bytes. In Unix, this isn't the case.
|> |> So, what should I use to write this field to the disk?
|>
|> short: 2 bytes
|> long:  4 bytes
|> int:   2 bytes with DOS, and 4 bytes with most UNIX systems

This is not guarenteed.  What is guarenteed is that short is *at* *least*
2 bytes - which is not what is wanted.  The only *portable* way to do this
is as follows:

 unsigned val;
 fputc(val&0xff, ofp);
 fputc(val>>8, ofp);

(assuming you want PC byte ordering in the value).

--
swf@elsegundoca.ncr.com  sarima@netcom.com

The peace of God be with you.

Stan Friesen (swf@ElSegundoCA.NCR.COM) wrote:
> In article <1994Aug31.083244.27454@news.unige.ch>, favre@medsun.unige.ch (Eric Favre) writes:
> |> In article <3416t8$r3b@vixen.cso.uiuc.edu>, db3565@ehsn13.cen.uiuc.edu (David G Baranec) writes:
> |> |> 1. The header for a TGA file requires that you write a 2 byte field. In DOS,
> |> |> this is no problem as an int type is 2 bytes. In Unix, this isn't the case.
> |> |> So, what should I use to write this field to the disk?
> |>
> |> short: 2 bytes
> |> long:  4 bytes
> |> int:   2 bytes with DOS, and 4 bytes with most UNIX systems

> This is not guarenteed.  What is guarenteed is that short is *at* *least*
> 2 bytes - which is not what is wanted.  The only *portable* way to do this
> is as follows:

>  unsigned val;
>  fputc(val&0xff, ofp);
>  fputc(val>>8, ofp);

To be pedantic, I think this is not correct.  What I read in the ARM is
that the minimum acceptible value for UINT_MAX is 65535.  It says nothing
about bytes.  On a mainframe with 36 bit words, it is conceivable that
an unsigned would be 18 bits, making UINT_MAX 262143.

This also raises [acedemic] questions about whether using 0xff and 8 in
your code offers any kind of guarantee.

To be pedantic :-)
--
Kevin J. Hopps                  e-mail: kjhopps@mmm.com
3M Company                      phone:  (612) 737-3300
3M Center, Bldg. 235-2D-45      fax:    (612) 737-2700
St. Paul, MN 55144-1000         Opinions are my own.  I don't speak for 3M.

   Quick question from a DOS programmer porting some code to Unix. First of
all, I'm running on an HP-715/75. I've written a ray-tracer, but I have a
few problems.

1. The header for a TGA file requires that you write a 2 byte field. In DOS,
this is no problem as an int type is 2 bytes. In Unix, this isn't the case.
So, what should I use to write this field to the disk?

2. Are there any Unix library equivalents to the biostime() <bios.h> calls
in DOS? I need to time the ray-tracer, but the functions in BC++ 4 aren't
standard on Unix systems. Are there any equialents?
Along those same lines, are there any Unix equivalents of wherexy(), and
gotoxy() (found in conio.h, in Borland)?

Thanks in advance for any responses I get. E-mail preferred, but feel free to
post to the newsgroups.

                                                 --**DAVE**--