I dont know if this is the right place to ask this question.


i got this book "The C Odyssey. Unix - The Open, Boundless C"
It is a 1992 edition book


The book speaks of all the unix specific functions


Just quoting an example below:


main()
{


int pid;
pid=getpid();
printf("Process id is \n",pid);



}


I would like to know if this should run on any linux flavour(since this

book talks only on unix/) with gcc compiler installed on it.What I
would like to know is if this book would prove useful to me if i would
like to play around with Linux. 

Thanks in advance

In article <1136097799.976366.131620@g49g2000cwa.googlegroups.com>,
 "fidlee" <fidlee@gmail.com> wrote:

> I dont know if this is the right place to ask this question.
> 
> 
> i got this book "The C Odyssey. Unix - The Open, Boundless C"
> It is a 1992 edition book
> 
> 
> The book speaks of all the unix specific functions
> 
> 
> Just quoting an example below:
> 
> 
> main()
> {
> 
> 
> int pid;
> pid=getpid();
> printf("Process id is \n",pid);
> 
> 
> 
> }
> 
> 
> I would like to know if this should run on any linux flavour(since this
> 
> book talks only on unix/) with gcc compiler installed on it.What I
> would like to know is if this book would prove useful to me if i would
> like to play around with Linux. 

Yes, it should run fine in any flavor of Unix or Linux.  The only 
Unix-specific function in that example is getpid(), and this hasn't 
changed significantly since the dawn of Unix.  The only change that's 
ever likely for it is the type of the result (to allow for larger 
process IDs); to minimize the impact of this, POSIX specifies a typedef 
pid_t rather than a specific type like int or long.

However, a 13-year-old book is pretty out of date, it will be missing 
most information about POSIX and SUS, not to mention Linux.  Why don't 
you get yourself something more recent?

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin wrote:
> In article <1136097799.976366.131620@g49g2000cwa.googlegroups.com>,
>  "fidlee" <fidlee@gmail.com> wrote:
>
> > I dont know if this is the right place to ask this question.
> >
> >
> > i got this book "The C Odyssey. Unix - The Open, Boundless C"
> > It is a 1992 edition book
> >
> >
> > The book speaks of all the unix specific functions
> >
> >
> > Just quoting an example below:
> >
> >
> > main()
> > {
> >
> >
> > int pid;
> > pid=getpid();
> > printf("Process id is \n",pid);
> >
> >
> >
> > }
> >
> >
> > I would like to know if this should run on any linux flavour(since this
> >
> > book talks only on unix/) with gcc compiler installed on it.What I
> > would like to know is if this book would prove useful to me if i would
> > like to play around with Linux.
>
> Yes, it should run fine in any flavor of Unix or Linux.  The only
> Unix-specific function in that example is getpid(), and this hasn't
> changed significantly since the dawn of Unix.  The only change that's
> ever likely for it is the type of the result (to allow for larger
> process IDs); to minimize the impact of this, POSIX specifies a typedef
> pid_t rather than a specific type like int or long.
>
> However, a 13-year-old book is pretty out of date, it will be missing
> most information about POSIX and SUS, not to mention Linux.  Why don't
> you get yourself something more recent?
>
> --
> Barry Margolin, barmar@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***
> *** PLEASE don't copy me on replies, I'll read them in the group ***

I tried running the above code on my computer having MontaVista's
flavour of Linux. It threw no warnings, but didnt give an output either

(output screen pasted below). What may be wrong? Is the type of the
variable pid causing the problem? I even tried changing the type to
long. but it still doesnt give any output.

root@(none):/tmp/tmptmp# gcc -o test pro1.c
root@(none):/tmp/tmptmp# test 
root@(none):/tmp/tmptmp#

It has no "%s" in the printf statement for one. For second, get a newer
unix book.

"fidlee" <fidlee@gmail.com> writes:

> Barry Margolin wrote:
>> In article <1136097799.976366.131620@g49g2000cwa.googlegroups.com>,
>>  "fidlee" <fidlee@gmail.com> wrote:
>>
>> > I dont know if this is the right place to ask this question.
>> >
>> >
>> > i got this book "The C Odyssey. Unix - The Open, Boundless C"
>> > It is a 1992 edition book
>> >
>> >
>> > The book speaks of all the unix specific functions
>> >
>> >
>> > Just quoting an example below:
>> >
>> >
>> > main()
>> > {
>> >
>> >
>> > int pid;
>> > pid=getpid();
>> > printf("Process id is \n",pid);
>> >
>> >
>> >
>> > }
>> >
>> >
>> > I would like to know if this should run on any linux flavour(since this
>> >
>> > book talks only on unix/) with gcc compiler installed on it.What I
>> > would like to know is if this book would prove useful to me if i would
>> > like to play around with Linux.
>>
>> Yes, it should run fine in any flavor of Unix or Linux.  The only
>> Unix-specific function in that example is getpid(), and this hasn't
>> changed significantly since the dawn of Unix.  The only change that's
>> ever likely for it is the type of the result (to allow for larger
>> process IDs); to minimize the impact of this, POSIX specifies a typedef
>> pid_t rather than a specific type like int or long.
>>
>> However, a 13-year-old book is pretty out of date, it will be missing
>> most information about POSIX and SUS, not to mention Linux.  Why don't
>> you get yourself something more recent?

A 13 year old book can still be very good.  Just do more what you
should do in any case: cross refer and check everything.  For example,
the first thing you should do when using or reading a function is to
read the man page (and if you're using a GNU system, the info page):

man 2 getpid

On my linux system man getpid indicates that getpid is conforming to
the following "standards": POSIX, BSD 4.3, SVID

(and you can check that indeed the returned type is no more int, but pid_t).


> I tried running the above code on my computer having MontaVista's
> flavour of Linux. It threw no warnings, but didnt give an output either
>
> (output screen pasted below). What may be wrong? Is the type of the
> variable pid causing the problem? I even tried changing the type to
> long. but it still doesnt give any output.
>
> root@(none):/tmp/tmptmp# gcc -o test pro1.c
> root@(none):/tmp/tmptmp# test 
> root@(none):/tmp/tmptmp#

What a funny little guy you are!

test is a command usually found in /bin, and your PATH certainly list
/bin, and not .

Try: ./test

but I'd avise you to avoid naming your test programs "test"!

Otherwise, there is a bug, the format string doesn't include any
directive to print the pid:

> printf("Process id is \n",pid);

Use:

  printf("Process id is %d\n",pid);

Here, I assume a pid_t is compatible with %d; perhaps I should not.
People more knowledgeable in printf could perhaps indicate a better
directive...


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.

Pascal Bourguignon wrote:
> "fidlee" <fidlee@gmail.com> writes:
>
> > Barry Margolin wrote:
> >> In article <1136097799.976366.131620@g49g2000cwa.googlegroups.com>,
> >>  "fidlee" <fidlee@gmail.com> wrote:
> >>
> >> > I dont know if this is the right place to ask this question.
> >> >
> >> >
> >> > i got this book "The C Odyssey. Unix - The Open, Boundless C"
> >> > It is a 1992 edition book
> >> >
> >> >
> >> > The book speaks of all the unix specific functions
> >> >
> >> >
> >> > Just quoting an example below:
> >> >
> >> >
> >> > main()
> >> > {
> >> >
> >> >
> >> > int pid;
> >> > pid=getpid();
> >> > printf("Process id is \n",pid);
> >> >
> >> >
> >> >
> >> > }
> >> >
> >> >
> >> > I would like to know if this should run on any linux flavour(since this
> >> >
> >> > book talks only on unix/) with gcc compiler installed on it.What I
> >> > would like to know is if this book would prove useful to me if i would
> >> > like to play around with Linux.
> >>
> >> Yes, it should run fine in any flavor of Unix or Linux.  The only
> >> Unix-specific function in that example is getpid(), and this hasn't
> >> changed significantly since the dawn of Unix.  The only change that's
> >> ever likely for it is the type of the result (to allow for larger
> >> process IDs); to minimize the impact of this, POSIX specifies a typedef
> >> pid_t rather than a specific type like int or long.
> >>
> >> However, a 13-year-old book is pretty out of date, it will be missing
> >> most information about POSIX and SUS, not to mention Linux.  Why don't
> >> you get yourself something more recent?
>
> A 13 year old book can still be very good.  Just do more what you
> should do in any case: cross refer and check everything.  For example,
> the first thing you should do when using or reading a function is to
> read the man page (and if you're using a GNU system, the info page):
>
> man 2 getpid
>
> On my linux system man getpid indicates that getpid is conforming to
> the following "standards": POSIX, BSD 4.3, SVID
>
> (and you can check that indeed the returned type is no more int, but pid_t).
>
>
> > I tried running the above code on my computer having MontaVista's
> > flavour of Linux. It threw no warnings, but didnt give an output either
> >
> > (output screen pasted below). What may be wrong? Is the type of the
> > variable pid causing the problem? I even tried changing the type to
> > long. but it still doesnt give any output.
> >
> > root@(none):/tmp/tmptmp# gcc -o test pro1.c
> > root@(none):/tmp/tmptmp# test
> > root@(none):/tmp/tmptmp#
>
> What a funny little guy you are!
>
> test is a command usually found in /bin, and your PATH certainly list
> /bin, and not .
>
> Try: ./test
>
> but I'd avise you to avoid naming your test programs "test"!
>
> Otherwise, there is a bug, the format string doesn't include any
> directive to print the pid:
>
> > printf("Process id is \n",pid);
>
> Use:
>
>   printf("Process id is %d\n",pid);
>
> Here, I assume a pid_t is compatible with %d; perhaps I should not.
> People more knowledgeable in printf could perhaps indicate a better
> directive...
>
>
> --
> __Pascal Bourguignon__                     http://www.informatimago.com/
> In deep sleep hear sound,
> Cat vomit hairball somewhere.
> Will find in morning.

Thanks a lot :)

On 2006-01-01, Pascal Bourguignon <spam@mouse-potato.com> wrote:
>> printf("Process id is \n",pid);
>
> Use:
>
>   printf("Process id is %d\n",pid);
>
> Here, I assume a pid_t is compatible with %d; perhaps I should not.
> People more knowledgeable in printf could perhaps indicate a better
> directive...

The appropriate thing to do when passing a variable of a type you don't
know about to a variadic function is to cast it. Say,

printf("Process id is %ld\n",(long int)pid);

[Usually you won't go wrong with long int or unsigned long int. You can
sometimes go with int or unsigned int.]

Jordan Abel <random832@gmail.com> writes:

> On 2006-01-01, Pascal Bourguignon <spam@mouse-potato.com> wrote:
>>> printf("Process id is \n",pid);
>>
>> Use:
>>
>>   printf("Process id is %d\n",pid);
>>
>> Here, I assume a pid_t is compatible with %d; perhaps I should not.
>> People more knowledgeable in printf could perhaps indicate a better
>> directive...
>
> The appropriate thing to do when passing a variable of a type you don't
> know about to a variadic function is to cast it. Say,
>
> printf("Process id is %ld\n",(long int)pid);
>
> [Usually you won't go wrong with long int or unsigned long int. You can
> sometimes go with int or unsigned int.]

Ok. Thank you.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"This statement is false."            In Lisp: (defun Q () (eq nil (Q)))

Jordan Abel wrote:

> The appropriate thing to do when passing a variable of a type you don't
> know about to a variadic function is to cast it. Say,
> 
> printf("Process id is %ld\n",(long int)pid);

Although this may be the best solution we know, there is no good general
solution to this problem. You have to  make a lot of assumptions about
the data type:

  o The type must be an alias for a primitive type (i.e. not a struct)
  o The type must have has a corresponding formatting specifier -- and
    you must know which (e.g. integer or float).
  o The type must have the appropriate signedness.
  o The type must have a size less than or equal to the cast type
    (remember that we also have long long and intmax_t).

C99 has solved these problems by defining a formatting modifier for each
type it defines (size_t, ptrdiff_t, and [u]intmax_t). That solution,
however, does not extend to other standards or your own types.

I am familiar with three solutions to this problem; none of which are
very attractive.

First, cast-to-largest as you suggest. With this solution you do not
have to know the size of the type, but you must know all its other
properties.

Second, define a formatting macro. Normally this is not done, so you
will have to detect it yourself (using autoconf or similar). With this
solution you avoid all problems (modulo non-primitive types), but it can
be tricky to write the detection code, and the resulting printf
statements can be rather difficult to read, especially for novices.

Third, for my own printf implementation I introduced a formatting
modifier (&) that allows you to specify the size. For example:

   printf("Process id is %&d\n", sizeof(pid), pid);

With this solution you solve the size problem, but still have all other
other problems. In fact, this solution assumes that integers are
reasonably well-behaved. For example, this solution will not work
correctly on a hypothetical platform where sizeof(int) == sizeof(long)
and where int is little-endian and long int is big-endian.

-- 
mail1dotstofanetdotdk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bjorn Reese <breese@see.signature> writes:

> Jordan Abel wrote:
>
>> The appropriate thing to do when passing a variable of a type you don't
>> know about to a variadic function is to cast it. Say,
>> printf("Process id is %ld\n",(long int)pid);
>
> Although this may be the best solution we know, there is no good general
> solution to this problem. You have to  make a lot of assumptions about
> the data type:
>
>  o The type must be an alias for a primitive type (i.e. not a struct)
>  o The type must have has a corresponding formatting specifier -- and
>    you must know which (e.g. integer or float).
>  o The type must have the appropriate signedness.
>  o The type must have a size less than or equal to the cast type
>    (remember that we also have long long and intmax_t).

[snip 3 solutions]

There is a fourth alternative, and that is to use C++ iostreams:

  #include <iostream>

  std::cout << "Process id is " << pid << '\n';

And if you really want to use format strings, use Boost.Format:

  #include <iostream>
  #include <boost/format.hpp>

  std::cout << boost::format("Process id is %1%\n") % pid;

Both of these have the advantage of being completely type-safe due to
using templates for the ostream output.  Of course, this does mean you
have to use C++, which may not be desirable.  I recently converted an
existing C project to C++, and made heavy use of the latter.  So far,
it's worked perfectly, and given me peace of mind knowing it can't
ever screw up.


Regards,
Roger

- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFDuTmmVcFcaSW/uEgRAt8SAKDgKv2zKvkfDKHYOQOnSlrHhyMUwACg6Olx
3mZDISF0wqwXA9q5x2pO1YE=
=65OH
-----END PGP SIGNATURE-----

On 2006-01-02, Bjorn Reese <breese@see.signature> wrote:
> Jordan Abel wrote:
>
>> The appropriate thing to do when passing a variable of a type you don't
>> know about to a variadic function is to cast it. Say,
>> 
>> printf("Process id is %ld\n",(long int)pid);
>
> Although this may be the best solution we know, there is no good general
> solution to this problem. You have to  make a lot of assumptions about
> the data type:

Or actually know these things

quoth the POSIX:
All of the types are defined as arithmetic types of an appropriate
length, with the following exceptions (list not including pid_t),
Additionally, (other stuff), and blksize_t, pid_t and ssize_t are signed
integral types.

>   o The type must be an alias for a primitive type (i.e. not a struct)
>   o The type must have has a corresponding formatting specifier -- and
>     you must know which (e.g. integer or float).
>   o The type must have the appropriate signedness.
>   o The type must have a size less than or equal to the cast type
>     (remember that we also have long long and intmax_t).
>
> C99 has solved these problems by defining a formatting modifier for each
> type it defines (size_t, ptrdiff_t, and [u]intmax_t). That solution,
> however, does not extend to other standards or your own types.

we need a sys/typeformat.h or something like that

printf("Process id is %" PRIiPIDT "\n", pid);

one could use the q8 inttypes.h as a starting point to write such a
thing.

> I am familiar with three solutions to this problem; none of which are
> very attractive.
>
> First, cast-to-largest as you suggest. With this solution you do not
> have to know the size of the type, but you must know all its other
> properties.

I suggested cast to long. This isn't "cast-to-largest" as such, rather, it's
making a bet, specifically, that no-one will have any use for more pids
than will fit in a long. Historically, no systems that I know of have
had any use for more than will fit in an int, (16-bit systems have used
16-bit pids, and even my current 32-bit system uses 5-decimal-digit
pids) so it seems like a fairly safe bet.

> With this solution you solve the size problem, but still have all other
> other problems. In fact, this solution assumes that integers are
> reasonably well-behaved. For example, this solution will not work
> correctly on a hypothetical platform where sizeof(int) == sizeof(long)
> and where int is little-endian and long int is big-endian.

or, more plausibly, the types are the same size with a different number
of significant (non-padding) bits)

On 2006-01-02, Roger Leigh <${rleigh}@invalid.whinlatter.ukfsn.org.invalid> wrote:
> And if you really want to use format strings, use Boost.Format:
>
>   #include <iostream>
>   #include <boost/format.hpp>
>
>   std::cout << boost::format("Process id is %1%\n") % pid;

boost formatting doesn't provide a way to select what base an output
format is in? [%d vs %o vs %x]?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jordan Abel <random832@gmail.com> writes:

> On 2006-01-02, Roger Leigh <${rleigh}@invalid.whinlatter.ukfsn.org.invalid> wrote:
>> And if you really want to use format strings, use Boost.Format:
>>
>>   #include <iostream>
>>   #include <boost/format.hpp>
>>
>>   std::cout << boost::format("Process id is %1%\n") % pid;
>
> boost formatting doesn't provide a way to select what base an output
> format is in? [%d vs %o vs %x]?

Yes, you can use all the common printf format specifiers.  The above
are purely positional markers for any type.

http://www.boost.org/libs/format/doc/format.html
gives a number of examples, if you are interested.


Regards,
Roger

- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFDucNhVcFcaSW/uEgRAnPNAJ42xW8MqXc9zzSv5bekV1ZQSAYDVgCgt0lE
SqgWVevcaSoYZUNF4FTsnTg=
=P9ib
-----END PGP SIGNATURE-----