Conference hydra::amiga_v1

    I'm new to C and also to Lattice so I could be dead wrong but .....
    
    I think you really need to look at 'clock'.  You declared it as
    a pointer then loaded it with a string, not an address.  Try this
    
    char clock[StringLengthYouWant];  /* different declaration */
    
    Then use 'clock' just like you did before in the other statements.
    C will automatically recognize a character array in your parameter
    passings and pass a pointer so you don't need to declare *clock.
    
    If this works on VAX then maybe the bug/inconsistency is really
    in VAX C, or it is a 'smarter' compiler.
    

No, I don't think anything's wrong with "clock". I've been using C for
years.  The value of a quoted string in C is it's address, and it is
perfectly legitimate to assign a char* to a quoted string in this way.
Note that you have the address of the literal string, and if you change
it, it's changed for good.

I don't have LATTICE-C, but in Mark Williams C for the Atari-ST, the
upper-case "%D" is used to refer to a "long" parameter, not an "int"
parameter.  I suspect that what is happening is that "sscanf" is
altering FOUR bytes of memory in returning the decimal values, rather
than the TWO you have declared by calling it an "int".  Under VAXC,
"int" and "long" are the same thing, as the natural size for integers
is 32 bits.  On the 68000, the natural size for integers is 16 bits.

I would suggest eigher changing the declaration of "hrs,mins,secs" to be
"long", or changing the sscanf string to "%2d:%2d:%2d".

>Note that you have the address of the literal string, and if you change

That was just an example. The real "clock" points to the current system
time (at one time anyway...)

> upper-case "%D" is used to refer to a "long" parameter, not an "int"

I remember reading this. I thought I tried both (originally it was "%d:%d:%d"
then I read the manual and tried capital "D". I was getting the numbers
but for some reason it would skip the first in teh source string:"

clock = "15:10:23";
sscanf(clock,"%d:%d:%d",&hrs,&mins,&secs);

returned hrs as 10, mins as 23, and secs as 0???

John
 
                                                                   

You know, this is *wierd*.

I tried the exact same test program posted, with the %D's changed to %d
and it worked as expected.

Re-reading the Lattice C manual, it says

on the Amiga, an "int" is the same as a "long int" and both are 32 bits. This
is true for 680x0 micros. If you want a 16 bit variable, use "short", and if
you just want the default integer for counters etc, use "int"


Now I'm somewhat confused. If "int" and "long int" are the same, then why
do %d and %D have any difference on an "int"??


Man, I'm sure spoiled by VAXC and DEBUG...

BTW, is there any GOOD symbolic debuggers availiable for Lattice C? Would
the MANX symbolic debugger work?


(and here's the $25,000 question:) do any of these debuggers provide
both C source *and* 68K assembly like VAX DEBUG does...


John (who's not used to scattering printf's all around...)

    
    re: -1
    
    There was a Usenet posting recently about Manx's new debugger. 
    Maybe someone still has it lying around.  Yes it does seem to supply
    assembly code for each line of C code.  The article also mentioned that
    Manx object files were now compatible with Amiga object files.  This 
    may mean the debugger will work for lattice (unless you have to compile
    without the debug switch to get the compatible files).
    
    - steve

re:	.4

Just for grins: Are you ABSOLUTELY shure that your original format string
was:

	"%d:%d:%d"

instead of:

	" %d:%d:%d"

or:

	":%d:%d:%d"

In either of the these two alternate versions the first integer could be
skipped (jumping over "white space"). I say "could" because some C scanf
scanners use the first white space specifier as an anchor while others
use it as an optional specifier.

Also, next time, print out the return value from scanf and see what it tells
you. I'm sure you'll get back a "2" instead of "3"... this is why the "seconds"
value was always a 0 (never written into).

Just some ideas...
dave

I started trying all sorts of funny games with the source string (like
adding a 00: to the front, to the back...) And then similar games with
the format string. I'll experiment more this weekend and post the results

John

>I tried the exact same test program posted, with the %D's changed to %d
>and it worked as expected.

Well, C *is* case-sensitive, so such behavior is not outside the realm
of "normal" C... 

>Re-reading the Lattice C manual, it says
>on the Amiga, an "int" is the same as a "long int" and both are 32 bits. This
>is true for 680x0 micros....

"int" is what the writer of the compiler thinks it is. Sometimes it's 32, 
sometimes it's 16. That's why you don't want to pass it to functions not
written in C. (i.e., "portable code"). The only *guarantee* is that an "int"
is no shorter than a "short" and no longer than a "long". Lattice is just
being arrogant in equating their definition of "int" with the Amiga's bus.
(Manx decided it was 16, so all arguments passed to functions have to be
cast as "long". Lattice is more compatible with Amiga's libraries, anyway...)

John O.

Re: .8

>Lattice is just being arrogant in equating their definition of "int"
>with the Amiga's bus.

Naw.  When I was looking for a C compiler for the Amiga, one of the
requirements I had at the time was that it support 32 bit ints. 
Unfortunately, it is very easy for assumptions about that sizeof int
to creep into programs, and sizeof (int) == sizeof (long) allows
you to port the maximum amount of poorly written software :-).

>Lattice is more compatible with Amiga's libraries, anyway...

I have often wondered: do the Amiga libraries assume 32 bit ints because
Lattice jumped on board with a 32 bit int compiler, or did Commodore
pick that because the Greenhills C compiler has 32 bit ints?  (I
don't know what int sizes are supported by Greenhills.)  (Greenhills,
by the way, is the C compiler Commodore uses to build the Amiga
software.)