[comp.sys.amiga] Examine and ExNext return codes

nor1675@dsacg2.UUCP (Michael Figg) (12/29/88)

.
.
In Rob Pecks' Programmer's Guide to the Amiga he says that Examine and 
ExNext return an int. Is this true or has it changed? The following code
seems to get success set to zero, but still goes through the while loop
once. There are about 30-40 files in the "src" directory so I would assume
that the while loop would print all of the entries instead of just exam.c
(which is in "src"). The code is like this:

int success;
.
.
lock = Lock(arg_path, ACCESS_READ);

fib = (struct FileInfoBlock *) AllocMem(sizeof(struct FileInfoBlock),
    MEMF_CLEAR);

success = Examine(lock,fib);
if (success)
{
  printf("\nFile name: %ls\n\n",&fib->fib_FileName[0]);
  while((success = ExNext(lock,fib)) != 0);
  {
    printf("Success equals %d\n", success);
    printf("File name: %s\n",&fib->fib_FileName[0]);
  }
  printf("Success equals %d\n",success);
}
.
.
Okay, I just noticed the ";" after the while statement which expains alot
but just changes the scope of the question to why am I getting zero? Also
in the first printf Rob uses a "%ls" which I have never seen before. In the
other filename printf I use a "%s". Both seem to work. I assumed that this
was an "l" as in long and not a 1 in the book. Any clues as to what is going
on here? The output from this looks like this (from memory):

File name: src

Success equals 0
File name: exam.c
Success equals 0

This was done with Lattice v5.0 and suppose now would be a good time to learn
CodePRobe, right? :-)  Some of the code is Robs' and some mine.

Thanks.
  
-- 
"Better graphics with crayons"                 Michael Figg
Have since switched to oil based paints        DLA Systems Automation Center
but find they really screw up the color        Columbus, Oh.
map and pens!                                  (614)-238-9036

nor1675@dsacg2.UUCP (Michael Figg) (12/29/88)

In article <246@dsacg2.UUCP>, nor1675@dsacg2.UUCP (Michael Figg) writes:
> .
>   while((success = ExNext(lock,fib)) != 0);
>   {
>     printf("Success equals %d\n", success);
>     printf("File name: %s\n",&fib->fib_FileName[0]);
>   }
>   printf("Success equals %d\n",success);
> }
> .
> Okay, I just noticed the ";" after the while statement which expains alot
> but just changes the scope of the question to why am I getting zero? Also
> in the first printf Rob uses a "%ls" which I have never seen before. In the



After I spent more than 5 seconds staring at this I realize that the output 
is probably what is expected since the while is probably going through all
the entries until it hits the end, then it prints the last entry and the zero
success. But am still curious about "%ls%. All this typing and the question
comes down to what does "%ls" give you? Does it have something to do with
the fact that "fib->fib_FileName[0]" being an address (pointer) therefore
a long, and not an int? Am I going to answer all my own questions?


Thanks again.



-- 
"Better graphics with crayons"                 Michael Figg
Have since switched to oil based paints        DLA Systems Automation Center
but find they really screw up the color        Columbus, Oh.
map and pens!                                  (614)-238-9036

higgin@cbmvax.UUCP (Paul Higginbottom MKT) (12/30/88)

In article <247@dsacg2.UUCP> nor1675@dsacg2.UUCP (Michael Figg) writes:
$[deleted broken program source]
$But am still curious about "%ls%.
$comes down to what does "%ls" give you? Does it have something to do with
$the fact that "fib->fib_FileName[0]" being an address (pointer) therefore
$a long, and not an int? Am I going to answer all my own questions?

String parameters (%s) in printf require pointers as arguments.  Prefixing
any format arguments in printf with "l" specifies that the INTEGER argument
is a LONG and not just a regular INT.  To print long values in hex for
example, you use "%lx".  I would expect printf parses but ignores "l" in "%ls".

I think Rob got carried away with "l" because they empirically worked. :-)

$Thanks again.

You're welcome.

$"Better graphics with crayons"                 Michael Figg
$Have since switched to oil based paints        DLA Systems Automation Center
$but find they really screw up the color        Columbus, Oh.
$map and pens!                                  (614)-238-9036

	Paul.

rap@ardent.UUCP (Rob Peck) (12/31/88)

In article <5596@cbmvax.UUCP>, higgin@cbmvax.UUCP (Paul Higginbottom MKT) writes:
> I think Rob got carried away with "l" because they empirically worked. :-)

Actually the "l' (small L) prepending that I had done shows my early
involvement with the Amiga OS, in that the printf built into the ROM
(or WCS), and accessible by linking in amiga.lib first, requires
all parameters to be longs.  Thus I still tend to use the 'l' most
of the time.  I so seldom want to print something containing a floating
point number that the limits of the ROM/WCS printf dont get in the way,
so this way the code is portable between compilers and link-libs.

By the way, Hiya Paul!

Rob Peck

higgin@cbmvax.UUCP (Paul Higginbottom MKT) (01/06/89)

In article <1088@ardent.UUCP> rap@ardent.UUCP (Rob Peck) writes:
$Actually the "l' (small L) prepending that I had done shows my early
$involvement with the Amiga OS, in that the printf built into the ROM
$(or WCS), and accessible by linking in amiga.lib first, requires
$all parameters to be longs.

But the tools you were using (Greenhills) had ints the same size as
longs anyway (32 bit), so wasn't the l unnecessary?

$By the way, Hiya Paul!

Hi to you Rob - good to see you on the net.

$Rob Peck

	Paul.

dale@boing.UUCP (Dale Luck) (01/06/89)

In article <5631@cbmvax.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom MKT) writes:
=In article <1088@ardent.UUCP> rap@ardent.UUCP (Rob Peck) writes:
=$Actually the "l' (small L) prepending that I had done shows my early
=$involvement with the Amiga OS, in that the printf built into the ROM
=$(or WCS), and accessible by linking in amiga.lib first, requires
=$all parameters to be longs.
=
=But the tools you were using (Greenhills) had ints the same size as
=longs anyway (32 bit), so wasn't the l unnecessary?

Nope, the tools were not Greenhills but Whitesmith C running on Sages.
We are talking history, ie BC (thats Before Commodore). When we moved
over to Sun's alot of the old practices did not change. Also the DoFmt
(or whatever it is called) in exec/debug library assume 16 bit ints.
This makes printing structures out easy.
For example:
struct point
{
	short x,y;
};

struct point a;

	could be printed out via

	printf("point(%d,%d)\n",a);


-- 
Dale Luck     GfxBase/Boing, Inc.
{uunet!cbmvax|pyramid}!amiga!boing!dale

dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (01/06/89)

:In article <1088@ardent.UUCP> rap@ardent.UUCP (Rob Peck) writes:
:$Actually the "l' (small L) prepending that I had done shows my early
:$involvement with the Amiga OS, in that the printf built into the ROM
:$(or WCS), and accessible by linking in amiga.lib first, requires
:$all parameters to be longs.
:
:But the tools you were using (Greenhills) had ints the same size as
:longs anyway (32 bit), so wasn't the l unnecessary?

	Right, if integers are 32 bits (sizeof(int) == 4), then the l
does not matter at all.  (scanf() uses a different character and in that
case it *is* needed).  However, if you intend your source to compile on
either type of compiler you had better get those l's straight!

	I found this out the hard way one day porting a small use-only-stdio
program to an IBM-PC.  Except for the cooked/raw I/O problem, my incorrect use
or non-use of 'l' in the printfs made for some fun debugging sessions!

						-Matt

peter@sugar.uu.net (Peter da Silva) (01/06/89)

In article <574@boing.UUCP>, dale@boing.UUCP (Dale Luck) writes:
> struct point
> {
> 	short x,y;
> };

> struct point a;

> 	printf("point(%d,%d)\n",a);
               ^^^^^^^^^^^^^^^^^^----- Aaaaaaaaargh!

You, man, are one sick puppy. I hope there are no goodies like this floating
around in the deliverable software. :-\
-- 
Peter "Have you hugged your wolf today" da Silva  `-_-'  Hackercorp.
...texbell!sugar!peter, or peter@sugar.uu.net      'U`

daveh@cbmvax.UUCP (Dave Haynie) (01/07/89)

in article <3226@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) says:
> Keywords: ints, Examine

> In article <574@boing.UUCP>, dale@boing.UUCP (Dale Luck) writes:
>> struct point
>> {
>> 	short x,y;
>> };

>> struct point a;

>> 	printf("point(%d,%d)\n",a);
>                ^^^^^^^^^^^^^^^^^^----- Aaaaaaaaargh!

> You, man, are one sick puppy. I hope there are no goodies like this floating
> around in the deliverable software. :-\

That is mutated.  Obviously, what you guys really wanted was C++, you perhaps 
just didn't know it.  Then you could have done:

	point a;

	cout << "point" << a << "\n";

And you get the proper ASCII representation of a point, like maybe (##,##)
or whatever you define in your point class, without resorting to kludgery
or compiler specific hacks.




> Peter "Have you hugged your wolf today" da Silva  `-_-'  Hackercorp.
> ...texbell!sugar!peter, or peter@sugar.uu.net      'U`
-- 
Dave Haynie  "The 32 Bit Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
              Amiga -- It's not just a job, it's an obsession

ewhac@well.UUCP (Leo L. Schwab) (01/07/89)

In article <574@boing.UUCP> dale@boing.UUCP (Dale Luck) writes:
:This makes printing structures out easy.
:For example:
:struct point
:{
:	short x,y;
:};
:
:struct point a;
:
:	could be printed out via
:
:	printf("point(%d,%d)\n",a);
:
	This assumes that the compiler pushes a copy of the structure onto
the stack.  I think there was a version of Manx that did something else (but
I'm not sure).  What does ANSI have to say about this operation?

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	INET: well!ewhac@ucbvax.Berkeley.EDU
 \_ -_		Recumbent Bikes:	UUCP: pacbell > !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor

thomas@cbmvax.UUCP (Dave Thomas QA) (01/09/89)

In article <10261@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
> In article <574@boing.UUCP> dale@boing.UUCP (Dale Luck) writes:
> :This makes printing structures out easy.
> :For example:
> :struct point
> :{
> :	short x,y;
> :};
> :
> :struct point a;
> :
> :	could be printed out via
> :
> :	printf("point(%d,%d)\n",a);
> :
> 	This assumes that the compiler pushes a copy of the structure onto
> the stack.  I think there was a version of Manx that did something else (but
> I'm not sure).  What does ANSI have to say about this operation?
> 
> _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
> Leo L. Schwab -- The Guy in The Cape	INET: well!ewhac@ucbvax.Berkeley.EDU

This wouldn't work on older C compilers. They would place a pointer to the
structure on the stack instead of the contents of the structure. The ANSI
standard says that the structure itself should be pushed.

           Dave
-- 
=============================================================================
   Dave Thomas               COMMODORE AMIGA TEST ENGINEERING
  // /_ |\/||/_ /_           UUCP  ...{allegra,ihnp4,rutgers}!cbmvax!thomas
\X/ /  \|  ||\//  \          PHONE 215-431-9328
=============================================================================