Prev: command line options for child process
Next: Stylistic questions on UNIX C coding.
From: Phred Phungus on 25 Feb 2010 23:31
Keith Thompson wrote:
> Phred Phungus <Phred(a)example.invalid> writes:

> Can you say a few more words about the macro expansion? Why would
>> #define _PC_NAME_MAX
>> not work in its stead?
>
> Because "#define _PC_NAME_MAX" would cause _PC_NAME_MAX to expand to
> nothing.
>
> In your program, you have a reference to _PC_NAME_MAX.
>
> The preprocessor sees "#define _PC_NAME_MAX _PC_NAME_MAX" and then
> replaces _PC_NAME_MAX by _PC_NAME_MAX. (This effectively does
> nothing, but the fact that it's #defined at all means you can use it
> with #ifdef.)
>
> Then during compilation, the identifier _PC_NAME_MAX resolves to the
> enumeration constant, so it's as if you had written 4.
>
> If instead the header had "#define _PC_NAME_MAX", it would still work
> with #ifdef, but the macro name would never resolve to the enumeration
> constant.
>


Alright, thanks for your extended comment, Keith. I think I have a
final question that shows the motivation for the entire thread.

Does ubuntu read /usr/include/bits/confname.h on booting to determine
this value?
--
fred
From: David Schwartz on 26 Feb 2010 05:23
On Feb 25, 8:31 pm, Phred Phungus <Ph...(a)example.invalid> wrote:

> Alright, thanks for your extended comment, Keith.  I think I have a
> final question that shows the motivation for the entire thread.

> Does ubuntu read /usr/include/bits/confname.h on booting to determine
> this value?

You mean the kernel itself? Of course not. The kernel doesn't read
header files. (And why would it? In case it somehow changed?)

DS
From: Phred Phungus on 1 Mar 2010 17:08
David Schwartz wrote:
> On Feb 25, 8:31 pm, Phred Phungus <Ph...(a)example.invalid> wrote:
>
>> Alright, thanks for your extended comment, Keith. I think I have a
>> final question that shows the motivation for the entire thread.
>
>> Does ubuntu read /usr/include/bits/confname.h on booting to determine
>> this value?
>
> You mean the kernel itself? Of course not. The kernel doesn't read
> header files. (And why would it? In case it somehow changed?)
>
> DS

Right. Alan commented elsethread:

> Not really... it is used to dynamically query the maximum allowable pathname
> length, which is a kernel limitation, but _PC_PATH_MAX and the other
> constants you can pass to pathconf() are just part of the libc interface. The
> kernel never sees them.
>
> _PC_PATH_MAX is a numeric constant, used by libc and the callers of libc
> (e.g. you) as part of the libc API.

So what *is* in the kernel?
--
fred
From: Alan Curry on 1 Mar 2010 19:10
In article <7v2s6oFsdrU2(a)mid.individual.net>,
Phred Phungus <Phred(a)example.invalid> wrote:
|Right. Alan commented elsethread:
|
|> Not really... it is used to dynamically query the maximum allowable pathname
|> length, which is a kernel limitation, but _PC_PATH_MAX and the other
|> constants you can pass to pathconf() are just part of the libc interface. The
|> kernel never sees them.
|>
|> _PC_PATH_MAX is a numeric constant, used by libc and the callers of libc
|> (e.g. you) as part of the libc API.
|
|So what *is* in the kernel?

By "in the kernel" do you mean in the kernel source, or in the compiled,
bootable, runnable image? The source uses PATH_MAX, #defined to 4096 in
include/linux/limits.h. Once it's compiled, #defines are gone, so it's just
the magic hardcoded number 4096.

--
Alan Curry
From: David Schwartz on 2 Mar 2010 21:58
On Mar 1, 2:08 pm, Phred Phungus <Ph...(a)example.invalid> wrote:

> So what *is* in the kernel?

More or less the same thing that's in user space code.

DS
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: command line options for child process
Next: Stylistic questions on UNIX C coding.